input checking for db.set

[jed]

felix,

i'm not sure what your end goal with dirty is, but i definitely respect your vision to keep it small. that said, there are some cases for which you might want to check inputs.

specifically:

db = require( "dirty" )( "test.db" );
db.set();
db = require( "dirty" )( "test.db" );

results in Error: Could not load corrupted row: {}.

also,

dirty = require( "dirty" );
db = dirty( "test.db" );
db.set( "someKey", function(){} );
db.get( "someKey" ); // [Function]
db = dirty( "test.db" );
db.get( "someKey" ); // undefined

the function will be persisted to memory but not to disk, meaning that the two are no longer consistent. this is clearly an edge case, but i was wondering where you see taking dirty in terms of preventing this kind of disparity/corruption.

[felixge]

Oh, I'm fine even if it would double in size. I just don't want to increase the overall scope / feature set of the project a lot.

I'll look into fixing this problem soon - it is definitely wrong.

[jed]

well, one problem becomes when you perform the check: making sure synchronously on-write that an object is JSON-stringifiable could be a performance hit. i guess you could do it upon persistence and provide an err argument in the callback to avoid that.

[felixge]

Oh, I don't think I'll check for JSON-stringifiability, if you pass in stupid stuff - expect stupid stuff to happen ; ). I will however fix that other bug you mentioned first.

[jeffreylin]

i'm sure you're aware already, but just in case...

db.rm() or db.rm(undefined) results in the same error (corrupting the database by adding '{}' to the append log)

thanks for such a great lib! =]

[felixge]

ifallacy: To be honest, I didn't have time to work on this lib for quite a while, but if you were to submit a patch for this, I'd take the time to review & merge.