You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using MongoDB in an app I'm developing Clibu and am especially interested in enabling Clibu to used offline. Ideally a Browser DB with a MongoDB compatible API would be used along with some sort of eventual consistency where Browser & Server DB's were updated to match whoever made the latest changes to a document. I have noticed your 'Replication' comment in Future plans, and wonder whether this meets my needs.
Along these lines you may be interested in swarm.js which is reactive data sync library which uses CRDT's.
FYI Clibu uses Websockets to push all database updates out to all clients as they occur.
I haven't looked at the FDB code however I get the feeling the DB itself is in memory and simply persists to disk. If that's correct then a large db will use a lot of memory. Can you clarify this?
Finally can I create an index on an array of document items. ex. doc: { name: fred, tags:[cat,dog,mouse] } and I want to index tags.
-Neville
The text was updated successfully, but these errors were encountered:
Sorry for the late reply to this one. The replication system will indeed be exactly what you are looking for so that data becomes eventually consistent.
FDB data is in memory as it is primarily designed as a browser database. Persistence in the browser is handled via IndexedDB, WebSQL and LocalStorage in order of availability. On the server side the landscape is a little different:
The server side of ForerunnerDB is still in development and although you have the ability to make remote calls and get remote data from a client connected to an FDB server, things like replication are not in place yet. The server-side will also have the ability to store in-memory or on disk, or a hybrid model where certain collections (or subsets of a collection) are stored in memory for fast access whilst less-read-intensive collections are stored and accessed via disk.
This is still work-in-progress server-side so while the above stuff is on the roadmap it is not ready for use. We've focussed primarily on making ForerunnerDB work well in browsers first as that is it's main use case for version 1.
If you have any thoughts on server-side features or have specific requirements that you'd like to see implemented let us know! The more we know about how people want to use Forerunner the better!
Regarding your index question I think the answer is no, not yet... but the index system is getting a nice upgrade soon to fix a bug with utilising indexes on ranged queries and I know the changes will make what you're asking possible.
I'm using MongoDB in an app I'm developing Clibu and am especially interested in enabling Clibu to used offline. Ideally a Browser DB with a MongoDB compatible API would be used along with some sort of eventual consistency where Browser & Server DB's were updated to match whoever made the latest changes to a document. I have noticed your 'Replication' comment in Future plans, and wonder whether this meets my needs.
Along these lines you may be interested in swarm.js which is reactive data sync library which uses CRDT's.
FYI Clibu uses Websockets to push all database updates out to all clients as they occur.
I haven't looked at the FDB code however I get the feeling the DB itself is in memory and simply persists to disk. If that's correct then a large db will use a lot of memory. Can you clarify this?
Finally can I create an index on an array of document items. ex.
doc: { name: fred, tags:[cat,dog,mouse] }
and I want to indextags
.-Neville
The text was updated successfully, but these errors were encountered: