Is CBLModel still in the pipeline for CBL 2.0?

[Brendan Duddridge]

As the subject says... Will you still be adding CBLModel to CBL 2.0?

Thanks,

Brendan

[Priya Rajagopal]

Hi Brenden

This will likely be a  2.x and not a 2.0 feature.

regards

-Priya

[Jens Alfke]

On Aug 7, 2017, at 6:06 AM, Priya Rajagopal <priya.r...@couchbase.com> wrote:

This will likely be a  2.x and not a 2.0 feature.

I’m sad about this, but we’re at that point (which I’m sure most of you are familiar with!) where we have to postpone some beloved features in order to get a reasonable release schedule. I know this is a blocker for you, and surely some other iOS/Mac developers, but 2.1 won’t take nearly as long as 2.0. And in my opinion, models should be the #1 feature for that release.

—Jens

PS: I’m not trying to pass the buck, but: models can be implemented on top of the document API without any access to private APIs. So it’s the kind of feature anyone could add. A good starting point would be the CBLModel implementation from 1.x, although it would be changed since documents behave differently. CBLDocument is mutable, which will simplify the model code a lot since it doesn’t have to store properties itself; but on the other hand documents are no longer uniqued (i.e. Database.documentWithID will return a new instance every time) which means there will probably need to be a weak-valued dictionary mapping docID⟶model.

[Brendan Duddridge]

Hi Jens,

PS: I’m not trying to pass the buck, but: models can be implemented on top of the document API without any access to private APIs. So it’s the kind of feature anyone could add. A good starting point would be the CBLModel implementation from 1.x, although it would be changed since documents behave differently. CBLDocument is mutable, which will simplify the model code a lot since it doesn’t have to store properties itself; but on the other hand documents are no longer uniqued (i.e. Database.documentWithID will return a new instance every time) which means there will probably need to be a weak-valued dictionary mapping docID⟶model.

No worries. I'm fine waiting for CBLModel. I still have to figure out how to sync with Apache CouchDB / Cloudant anyway and I have no idea how to start with that. I really wish you had a compatibility layer or something to help with the transition in that area. Can I pay you to build one?

But not having uniquing is definitely a new twist on things. Is that something you would build-in to the CBLModel implementation or is that left as an exercise for the developer?

Thanks,

Brendan

[Jens Alfke]

On Aug 7, 2017, at 10:25 AM, Brendan Duddridge <bren...@gmail.com> wrote:

No worries. I'm fine waiting for CBLModel. I still have to figure out how to sync with Apache CouchDB / Cloudant anyway and I have no idea how to start with that. I really wish you had a compatibility layer or something to help with the transition in that area. Can I pay you to build one?

Oof, this would amount to writing a new replicator for the CouchDB/1.x REST protocol, or at least ripping the old replicator out of the CBL 1.x Objective-C sourcebase and making it work with 2.0. Either of those would be quite a bit of work. At this point, after six years, I’m personally ready to say goodbye to that protocol and I don’t really need the extra cash :)

But not having uniquing is definitely a new twist on things.

Yes, it is. I’ve always been a fan of uniquing, and it was a bit difficult to let go of it, but this was important for making multithreading work with mutable Document objects. For example, if you have a Database object and two threads concurrently get the document “foo”, you don’t want them to get the same Document object, or all of their individual property changes will step on each other. Instead you want isolation between threads so that each will see only the original state and its own changes. (Of course they will run into conflicts if both save, but that just involves merging two individually-consistent revisions, which is cleaner.)

Is that something you would build-in to the CBLModel implementation or is that left as an exercise for the developer?

Yeah, I think that with model objects you really need uniquing, otherwise things get really weird, especially as you follow references between models. For example, let’s say documents “alice” and “bob” both have a property ‘mother’ that refers to the person’s mother

let alice = MyModel(db, “Alice”)

let aliceMom = alice.mother

let bob = MyModel(db, “Bob”)

let bobMom = bob.mother

Let’s say Alice and Bob are siblings. Then I would expect aliceMom and bobMom to refer to the same object, otherwise you can get weird behaviors where you change a property via one reference and don’t see it in the other reference.

Fortunately uniquing is pretty easy to do. In the Obj-C 1.x implementation it’s done with a class called CBLCache.

—Jens