obeliskos
commented
10 years ago Interesting post. We can possibly rename our id column to avoid clashing with existing id columns. You will have to manually apply indexes to your own id columns (or originalId for now). If you apply an index to originalId (for now), you will gain significant performance increases on find() ops against that column.
As for synchronicity, I will defer to Techfort but at least while feature set is being worked out, leaving synchronous makes it much easier to benchmark, test, and debug. Maybe for certain key functions we could support async as option.
Promises may add polyfill dependencies (for now) but in theory I like the idea and would definitely like to support it once it becomes native to node / ecma 6 browsers. I will start looking into level of effort for whenever/if we decide to add support for that.
techfort
jlchereau
Use Case
I work on a project involving the MEAN stack (without A). This project is divided into RESTful API server(s) and Web UI Server(s). We needed a way to mock data access and instead of using SinonJS to mock $.ajax requests we have deemed simpler to mock data access with a second set of observable models getting data and setting data to an in-memory database.
Reasons for choosing LokiJS
We have quickly evaluated PouchDB, TaffyDB, Lawnchair, DB.js, jQuery.IndexedDB.js, minimongo, etc. Just from reading the documentation we felt that having an in-memory database that would match mongoDB apis would make things simpler and since minimongo requires Browserify, we tunred to LockiJS.
On the long run, we need a database to store JSON documents in a Cordova app that we want to synchronize with our RESTful server backed by MongoDB, and this QA/test mockup exercise seemed like a good way to evaluate LokiJS.
Disappointments with LokiJS
Basically, everything that is good and appealing in LokiJS pertains to its resemblance with MongoDB. The bad comes from the differences.
The main issue with LokiJS is ids. IMHO, renaming an id of type string (actually a MongoDB ObjectId converted to a string) into originalId to have an id of type number is a terrible option that leads to all sorts of headaches either in our mockup scenario and most certainly in synchronization scenarios. In other words, do not change ids. As we have documents that reference documents in other collections, we could only use find({originalId: 'xxxxxxxxxxxxxxxxxxxxxxxx'}), and since we have never been able to use get, I doubt there is any performance benefit (unless LokiJS is used in scenarios that do not involve MongoDB, but then why all the fuss about matching its API?).
The second important issue is synchronicity. We heavily use callbacks in our server code and promises in our browser/cordova code. Using a deferred and setTimeout to wrap all synchronous code is tedious. In the long run, LokiJS should think about a plugin architecture for persistence to WebSQL, IndexedDB, localStorage and use callbacks/promises for all data access functions.
Opportunity
There is a real opportunity for LokiJS. IMHO, this is to become the PouchDB of MongoDB, not another light database that resembles more or less MongoDB and that requires all sorts of workarounds to make it store and find MongoDB documents.
Although there might be an opportunity for LokiJS to be competitive as a nodeJS database that I do not grasp, I recommend considering focusing on browser and cordova scenarios (including synchronization) where there is a definitive gap/need. At least, we have this need.
This is just one user's feedback that might trigger some thoughts. I hope this helps.