TingoDB API is fully compatible with MongoDB. Difference is only initialization and obtaining of Db object.
require(‘tingodb’)(options)
In contrast to MongoDB, module require call will not return usable module. It will return a function that accept configuration options. This function will return something similar to MongoDB module. Extra step allows to inject some options that will control database behavior.
nativeObjectID: true|false Default is false
Doing some experimentation we found that using integer keys we can get database work faster and save some space. Additionally for in-process database there are almost no any drawbacks versus globally unique keys. However in the same time it is relatively hard to keep unique integer keys outside of the database engine. So we make it part of the database engine code. Generated keys will be unique in collection scope.
When required it is possible to switch to BSON ObjectID using the configuration option.
cacheSize: integer Default is 1000
Maximum number of cached objects per collection.
cacheMaxObjSize: integer Default is 1024 bytes
Maximum size of object that can be placed to cache.
searchInArray: true|false Default is false
Globally enables support of search in nested array. MongoDB support this unconditionally. For TingoDB search in arrays when there are no arrays is performance penalty. That’s why it is switched off by default.
Additionally, and it might be better approach, nested arrays support can be enabled for individual indexes or search queries.
To enable nested arrays in individual index use “_tiarr:true” option.
self._cash_transactions.ensureIndex("splits.accountId",{_tiarr:true},cb);
To enable nested arrays in individual query for fields that do not use indexes use “_tiarr.” prefixed field names.
coll.find({'arr.num':10},{"_tiar.arr.num":0})
new Db(path, options)
The only required parameter is database path. It should be valid path to empty folder or folder that already contain collection files.