how to cascade delete to many relationship

[Joel Saltzman]

Let's say I have a model (subclass of CBLModel) with many children. 

Is this the suggested way of setting up the relationship? 

Is there a better way to do it so when the parent gets deleted, the children get deleted too?

MYModel *parent = [MYModel initWithNewDocumentInDatabase:_database];

parent.children = [NSMutableArray new];

MYModel *child = [MYModel initWithNewDocumentInDatabase:_database];

[child save:NULL];

[parent.children addObject:child];

[parent save:NULL];

[Jens Alfke]

On Feb 22, 2014, at 2:39 PM, Joel Saltzman <saltzm...@gmail.com> wrote:

Let's say I have a model (subclass of CBLModel) with many children. 

Is this the suggested way of setting up the relationship? 

Yes; assuming that you’ve defined a MyModel.children property, marked it as @dynamic in the implementation, and implemented a +childrenItemClass method that returns MyModel.

Is there a better way to do it so when the parent gets deleted, the children get deleted too?

No, there’s no support for cascading deletes. CBLModel doesn’t do everything CoreData does, although it does keep getting closer.

If you want this behavior you’d need to override -deleteDocument: and delete each of the child objects. (You might need some kind of protection against infinite regress, if your relationship can have cycles.)

—Jens

[Joel Saltzman]

Awesome. I did it right. Thanks for the weekend support!

[Laurent W]

Hello Joel and Jens,

We had the same issue to have models with a parent/children relationship. 

We started with the same solution but we realized it was not possible to do as in a relational database because of synchronisation issues.

Effectively, what would happen if a parent is synchronized with a pull or push while it is not the case of one of its children because the communication stops precisely at the wrong time ? 

In fact, we may have a pb of consistency.

So, instead, we decided to use the nested objects (as soon they were!) implemented by Jens. In such case, parent and children are saved inside the same document and thus, there is no issue in terms of consistency.

Furthermore, cascading delete is straightforward: if you remove the parent, it removes the children too !

Nested objets involve some work, but we think -and we hope !- it worth it (we choose to generate the code from the Xcode entity model tool, so it is no more a difficulty for us).

Laurent

[Joel Saltzman]

Interesting. 

What does the model look like then? 

Are there separate parent and child models in your case?

What is the Xcode entity model tool? Are you talking about the core data tool?

--
You received this message because you are subscribed to a topic in the Google Groups "Couchbase Mobile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mobile-couchbase/mVIJQ0s_pS4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mobile-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/be76cf92-f59a-4638-907d-caa18610554f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Laurent W]

Le dimanche 23 février 2014 22:59:53 UTC+1, Joel Saltzman a écrit :

Interesting. 

Yes ! We have a lot of fun with CouchBaseLite !

And we use the core data tool to design our models. We take advantage of the 'User Info' in the data model inspector to precise our specific information. For example, we use it to specify whether a model is a nested or a root.

Generated classes inherit from CBLModel for root models, and from our own root class for nested models.

Our end-user classes inherit from generated classes so it is easy to regenerate code when modeling changes.

And of course, we use separate parent and child models because we want to be able to reuse child models. 

For example, an address model is nested in many different models. Even if we need to access to parent specific features in a children, it is not an issue: we just ask the parent to implement a protocol.

A big advantage of our tool is to generate code for  nested (To One or ToMany, handling json serialization), attachments (for example, images), validation, labels, and other issues.

We did the same thing on the graphic user interface, we reuse the 'detail view' so it is fully object oriented. For example, in a coordinate model, there are nested emails, nested urls, nested phone numbers and a nested address. In the detail of coordinate, we just put a CustomView for each nested giving it the name of relation. 

After, when we load the detail of coordinate, it loads automatically the master/details of the nested ToMany relation or the detail of the nested ToOne relation. We handle issues such as adjusting priority levels for constraints!.

So we can play to 'lego' buidling our end-user application.

For now, our application is under Mac OS, but we aim to synchronize with applications on iPad or mobile taking full advantage of CouchBaseLite and CouchDB/CouchBase technologies.

Laurent

laur...@yahoo.com 

[Ragu Vijaykumar]

This sounds like a fascinating idea - any chance you might contribute your code to selectively make classes nested within a CBLModel?

[Laurent W]

Hello Ragu,

I think it is possible to share this code with the community ! 

However, I have no available time to undertake support for it and thus ensure success of it, because I make this tool to develop a product we aim to commercialize at the end of the year.

This product is under Mac OS and use rich interfaces.

So to give a chance to such an abstract layer above CouchBaseLite, I would prefer CouchDB or CouchBase communities to organize things.

I will prepare a demo and document on my spare time, submit it to the community, and keep you informed,

Laurent

[Jens Alfke]

On Apr 14, 2014, at 5:06 AM, Laurent W <lau...@gmail.com> wrote:

I think it is possible to share this code with the community ! 

Definitely. Three options I can see:

(a) Submit a pull request to our repo; even if we don’t incorporate it, other people can download and merge the patch themselves for their own use;

(b) or fork our Couchbase Lite repo and add your own changes;

(c) or create a separate library that uses CBL and publish that.

Option (c) is best if you can structure your code so it doesn’t require changes in CBL itself. (a) is convenient for really small changes but gets awkward if the change has to be maintained as CBL develops; (b) makes it easier for you to maintain the change, but means you’ll need to keep updating your repo from upstream and merging changes.

Probably the best thing is if you can come up with a minimal set of changes to CBL that are needed to make your stuff work, and submit those via (a). Once they’re merged, you can publish the rest as (c) and not be so closely tied to having to track changes in CBL.

—Jens