Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

General questions, including Server sync #21

Closed
nevf opened this issue Dec 14, 2014 · 1 comment
Closed

General questions, including Server sync #21

nevf opened this issue Dec 14, 2014 · 1 comment
Labels

Comments

@nevf
Copy link

nevf commented Dec 14, 2014

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

@Irrelon
Copy link
Owner

Irrelon commented Jan 23, 2015

Hi Neville,

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.

All the best!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants