I was looking through the code and I saw that the onMutateBlock seems to 
only ever be set in a CBLJSONEncoding object when the CBLModel is loading 
its contents from a CBLDocument. But what about the first time the 
CBLJSONEncoding object is created and assigned to a CBLModel? Let's say the 
model is saved, program is still running, user makes changes to the 
CBLJSONEncoding child object - how does one notify the parent CBLModel that 
it needs to be saved since the onMutateBlock was never set?

Pseudo-code:
CBLModel* model = new CBLModel;
CBLJSONEncoding childModel = new CBLJSONEncoding;
model.childModelProperty = childModel;
model.save;

childModel.property = new value;
childModel.onMutateBlock();                                       // 
Supposed to do, but onMutateBlock is nil

Thanks for all your help!

Cheers,
Ragu

On Thursday, April 10, 2014 7:01:01 AM UTC-7, Jens Alfke wrote:
>
>
> On Apr 10, 2014, at 6:37 AM, Ragu Vijaykumar <[email protected]<javascript:>> 
> wrote:
>
> Does this mean that if my object implementing CBLJSONEncoding is at all 
> mutable, I need this class? And if so, does it mean that anytime I change 
> any of its instance variables / properties, I need to call the onMutate 
> block?
>
>
> Yes. The parent model object needs to know when its in-memory state has 
> changed, so that it can set its needsSave flag. Otherwise it won’t get 
> saved back to the document it came from. Normally it can do that easily by 
> just noticing when any of its property setters are called. But if a 
> property value is a custom class implementing CBLJSONEncoding, then that 
> value might itself be mutable and the model can’t tell when it changes.
>
> So what your class should do is implement that method and store the 
> onMutate block in an instance variable, then call that block right after 
> its persistent state changes. That will notify the model, which will set 
> its own needsSave flag.
>
> If the above answers are yes, is there any clean way I can just observe 
> changes to all my properties and automatically call this block, perhaps as 
> a generic superclass to any nested child classes of a CBLModel?
>
>
> Interesting idea. I think that would work. You might even be able to use 
> the Obj-C runtime’s reflection APIs to automatically discover all of the 
> class’s mutable properties and iterate over them. Let us know if you come 
> up with something.
>
> —Jens
>

-- 
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/9469ecfb-6974-4b0d-8ba4-5b9789c692df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to