1 out of my 10 test runs ended with mysterious error. Changes done short after the database was open where reverted to original state. The root cause is that when instance of db is created it initiates implicit open of the db. Now if you call explicitly open after you create instance db (because you want your callback to be called when the db is truly opened), that means you have two opens running concurrently. If the explicit open completes before the implicit open and further code modifies the database, the implicit open will revert those changes as it loads objects from the database file.
The callback handling in sculejs is very fragile and requires major redesign. This is just a quick fix for this particular race condition without making incompatible changes to sculejs API.
1 out of my 10 test runs ended with mysterious error. Changes done short after the database was open where reverted to original state. The root cause is that when instance of db is created it initiates implicit open of the db. Now if you call explicitly open after you create instance db (because you want your callback to be called when the db is truly opened), that means you have two opens running concurrently. If the explicit open completes before the implicit open and further code modifies the database, the implicit open will revert those changes as it loads objects from the database file.
The callback handling in sculejs is very fragile and requires major redesign. This is just a quick fix for this particular race condition without making incompatible changes to sculejs API.