Open duncanbrown opened 10 years ago
Seems like an edge case indeed but still worth solving. Thanks for reporting, I'll see when I have the time to fix it :)
fyi, this is my workaround by running fs.mkdir once if the flag local.swgg.modeNedbInitialized is not set
local.swgg.collectionCreate = function (schemaName) {
/*
* this function will create a persistent nedb-collection from schemaName
*/
if (!local.swgg.cacheDict.collection[schemaName]) {
if (local.modeJs === 'node' && !local.swgg.modeNedbInitialized) {
// init nedb dir
local.fs.mkdir('tmp', local.utility2.nop);
local.fs.mkdir('tmp/nedb.collection', local.utility2.nop);
}
local.swgg.modeNedbInitialized = true;
local.swgg.cacheDict.collection[schemaName] = new local.swgg.Nedb({
autoload: true,
filename: 'tmp/nedb.collection/' + schemaName,
timestampData: true
});
}
return local.swgg.cacheDict.collection[schemaName];
};
Bit of an edge case this, but...
Calling
ensureIndex
on a Datastore gives an error when all the following are true:loadDatabase
may have been called, but the executor has not yet got round to carrying it out)The error comes about because calling
ensureIndex
results in a (synchronous) call toPersistence.prototype.persistNewState
, which in turn callsfs.appendFile
, all beforePersistence.prototype.loadDatabase
has been called. This may ordinarily go unnoticed because if 4. above is not true thenfs.appendFile
will actually create the db file.I've spent a while thinking of a solution to this, but I can't come up with anything that keeps
ensureIndex
synchronous (short of synchronously checking that the db file exists every time it is called).