Ready for production?

[mrjjwright]

I love what I see here and was planning on trying this on an app that is currently using LevelDB. Is this lib ready for production apps?

Thanks for the great work!

John

[snej]

I don't know. It's being used in Couchbase Lite 1.1 (i.e. the current master branch) which is still in development. It feels fairly stable. But I'm sure using it something else will stress it in different ways and issues might come up.

So I can't promise anything. But I'd be interested in having you try it out.

[mrjjwright]

Ok great, I am leaning towards giving it a shot. The only other options for me that work on iOS are LMDB and LevelDB, both of which have significant drawbacks. I need real transactions and the LMDB memory mapped model won’t work well on mobile.

On Apr 6, 2015, at 10:03 AM, Jens Alfke notifications@github.com wrote:

I don't know. It's being used in Couchbase Lite 1.1 (i.e. the current master branch) which is still in development. It feels fairly stable. But I'm sure using it something else will stress it in different ways and issues might come up.

So I can't promise anything. But I'd be interested in having you try it out.

—
Reply to this email directly or view it on GitHub #5 (comment).

[mrjjwright]

So I got it working. I decided to use the ForestDB api directly but I did have to use your Slice class. Thanks so much! I am curious as to why you only allow one transaction per database file in CBForest. Doesn't ForestDB support concurrent writes?

[snej]

It does, but (a) it doesn't support full isolation of transactions yet (see the doc-comment for fdb_begin_transaction()), and (b) I didn't want to deal with having to back out and retry a transaction if there's a collision.

[mrjjwright]

Got it. Thank- you!

[mrjjwright]

One other thing. One approach I am considering in isolating my app’s access of ForestDB into a few different key stores (representing logical areas of the app) within a single file. Each keystone would have a serial GCD queue to maintain isolation, along with separate file and key store handles. This will increase the throughput of my app, provide some nice logical containers, and ensure serialization of transactions for a particular keystore.

Do you know of any big drawbacks of using multiple key stores within a single forest db file?

Btw, I heard that ForestDB will be getting full ACID transactions within the year. Yay for that!

On Apr 7, 2015, at 7:16 PM, Jens Alfke notifications@github.com wrote:

It does, but (a) it doesn't support full isolation of transactions yet (see the doc-comment for fdb_begin_transaction()), and (b) I didn't want to deal with having to back out and retry a transaction if there's a collision.

—
Reply to this email directly or view it on GitHub #5 (comment).

[snej]

Multiple key-stores should be fine. They're implemented using key prefixes, but the way ForestDB's tree (trie) structure works, there's very little overhead to that.