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 [email protected] > 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? > > On Feb 23, 2014, at 1:23 PM, Laurent W <[email protected] <javascript:>> > wrote: > > 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 > > > Le dimanche 23 février 2014 00:17:29 UTC+1, Joel Saltzman a écrit : >> >> Awesome. I did it right. Thanks for the weekend support! >> >> On Saturday, February 22, 2014 3:15:58 PM UTC-8, Jens Alfke wrote: >>> >>> >>> On Feb 22, 2014, at 2:39 PM, Joel Saltzman <[email protected]> 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 >>> >> -- > 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 > [email protected] <javascript:>. > 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. > > -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/07eab4ff-7210-4433-af5a-1f83de968054%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
