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

Le mercredi 9 avril 2014 23:07:12 UTC+2, Ragu Vijaykumar a écrit :
>
> This sounds like a fascinating idea - any chance you might contribute your 
> code to selectively make classes nested within a CBLModel?
>
> On Monday, February 24, 2014 3:03:22 AM UTC-8, Laurent W wrote:
>>
>>
>> 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]> 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].
>>> 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/1e8681e3-685b-4448-9e6b-7229cd134582%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to