Use jshint to enforce. editorconfig might not be a bad idea either.

Add tests to confirm that data can be imported using mongoimport. Great if it could be exported using mongoexport as well. (Can each collection file continue to be an array given the 16 Mb import limit? What will the difference be when mongoexport is called without --jsonArray?)

https://github.com/maxogden/dat

Documentation for different fields and their meanings.

$ bin/mrd add tracks 1 2
_id must be a string, got number

http://google-styleguide.googlecode.com/svn/trunk/jsoncstyleguide.xml#Flattened_data_vs_Structured_Hierarchy

In particular, property names should be camel-cased.

Releases need a type code or something so that we can specify if it's a CD, an LP, a 7" single, an EP, a live performance, an Internet download, streaming performance, film, television, etc.

Should make sure it has no associations and/or delete all associations

example/load should be in a test dir and it should use data.js rather than loading the JSON itself. It should also specify collection names fully, like artist_track rather than at.

Make npm test run grunt, rather than grunt run npm test. This will require us to put the sanity check script into grunt, but that should be easy with grunt-exec which we're already using.

Then npm test can run grunt instead of the sanity check script.

This way, both grunt and npm test will test everything.

And Travis-CI will test everything.

Instead of rv.status and StatusEnum and rv.message etc., use an event emitter. https://www.youtube.com/watch?v=B6X83J2Dv8E starting around 16:45

Provide a sample app that uses the data.

Do not set outputDir property or sent dataDir as an option in the Constructor.

Instead, send outputDir as an option for write() and send dataDir as an option for load() (which should be extracted out of the constructor).

There should probably be no default dataDir/outputDir in the data module but possibly in the cli module.

Say, changing the names array.

Deploy to stackdock.com perhaps?

https://github.com/gruntjs/grunt-contrib-yuidoc

Use jshint and editorconfig to enforce.

Keep it simple: Just add an entry to tracks.json. Relationships should be handled separately. The programmatic sanity checking is what should protect against partial updates. The tools library should just do tiny things that can be assembled by more sophisticated tools.

Only minimal fields for now. Add new fields only as their needed.

the R in CRUD

Should be able to look up an individual and get enough information to determine if it's the person you are actually looking for. For example, if I look up Roger Taylor, it shouldn't just give me people named Roger Taylor. It should give me "Roger Taylor, member of Queen" and "Roger Taylor, member of Duran Duran".

Needs some refactoring so that there's a data object and a cli object.

If we're going to have a big honkin' JSON file, perhaps it should be built from smaller, more manageable JSON files, eh?

It might be tempting to have a releases file, an artist file, etc. But consider if it might make more sense to organize it by artist with each artist having their own file or something like that.

Use optimist, eh? https://www.youtube.com/watch?v=B6X83J2Dv8E

Instead of a fixture, make Data start with nothing, include a load() method to load from a data directory, and only use a fixture to test the load() function. The CLI may default to the current default data directory. But otherwise, a Data object will just have an empty object. Tests can add the necessary entries themselves to test for rejection of duplicate _ids etc.

This way, the fixture won't become this thing that can never be refactored because you won't know what tests you're making useless, etc.

The sanity checker should tell me what IDs are missing when there are IDs that should appear in a relationship table but don't.

Perhaps via grunt task? Basically enforce rules that a relational database might enforce such as:

• every entry must have certain required properties
• If this artist is tied to that album, then that album better think it's tied to this artist

Should be able to look up an individual and get enough information to determine if it's the person you are actually looking for. For example, if I look up Roger Taylor, it shouldn't just give me people named Roger Taylor. It should give me "Roger Taylor, member of Queen" and "Roger Taylor, member of Duran Duran".

At a minimum, run jsonlint as part of CI

find should not return an array of results, but should instead return an object so that it can also include a status and message

It exits with a success status code but doesn't actually write anything if no output directory is specified. It should return an error status code and an error message instead.