Closed JoshuaPeddle closed 2 years ago
The big thing to note is that you haven't duplicated this in responses.js. This isn't a problem for the PR, but just don't forget, there was something like that this morning though I can't remember it for the life of me now.
Other than that, I reviewed and did some cursory testing, I could not find any negative impact on the program.
Finally, On the _id thing, it's not written into the .tsv so there's no reason to even bother. It may even be helpful to have the _id value for constructing tests, so you should definitely leave it if it won't cause issues.
(I know I haven't really done anything since this morning - sorry about that. I think I'll have time tonight to update the docs, so I'll do that much more at least)
All good. I have 4820 now till about 9PM but I'll publish the code and tests for responses.js / response.js when I get back.
Had to make a few small tweaks throughout. This may functionally change a bit as the project continues.
controllers/usages.js: added controller method for exporting tsv
model/usage.js added method to save array of Usages
server-app.js added new route for TSV export enable support for JSON bodies
test.js added one test for exporter
.gitignore add 'usage_export.tsv' so it's not constantly tripping out source control.
I've noticed one kind of inconsequential bug. When we retrieve our items from the database we don't convert them a new Response or new Usage first so they keep the '_id' field. Not a hard fix but would rather do it after we get this PR out of the way.