CBLModel property vs. NSArray of CBLModels

[Ragu Vijaykumar]

I was reading the documentation and came across this note when making a property refer to another CBLModel. I have no problem designating my relationship weak, but if I were to make an NSArray of CBLModels (to many relationship), doesn't the NSArray hold strong references to the models it contains? I'm just trying to reconcile why CBLModel properties themselves should be weak, but arrays of CBLModels are held strongly...

For example, you might have documents for blog comments and each blog comment has a post property whose value is the document ID of the blog post it refers to. You can model that like this:

@class BlogPost;

@interface BlogComment : CBLModel
@property (assign) BlogPost* post;
@end

In the implementation of BlogComment you declare the property as @dynamic, like any other model property.

Note that the declaration uses (assign) instead of the more typical (retain). This is because a relationship to another model doesn’t retain it to avoid creating reference-loops that can lead to memory leaks. Couchbase Lite takes care of reloading the destination model if necessary when you access the property. Also, Couchbase Lite does not deallocate models with unsaved changes.

Thanks, 

Ragu

[Jens Alfke]

On Apr 10, 2014, at 3:59 PM, Ragu Vijaykumar <ra...@scrxpt.com> wrote:

I was reading the documentation and came across this note when making a property refer to another CBLModel. I have no problem designating my relationship weak, but if I were to make an NSArray of CBLModels (to many relationship), doesn't the NSArray hold strong references to the models it contains?

No, it actually uses a custom NSArray subclass (CBLModelArray) that fetches model objects on demand. It stores only the document IDs (as in the JSON), and the -objectAtIndex: method looks up and returns the document with the corresponding ID.

I'm just trying to reconcile why CBLModel properties themselves should be weak, but arrays of CBLModels are held strongly...

I was careful to make references to models weak because of the possibility of cycles, which would otherwise cause the models involved to stay in memory forever.

(Note that models with unsaved changes are always kept in memory until saved, so you’ll never lose changes as a result of weak-referenced models being dealloced.)

—Jens

[Ragu Vijaykumar]

Oh, ok. Does that mean that the NSArray property itself should be held weak, or strong? Also, what about properties that point to NSObjects<CBLJSONEncoding>? should those be held as strong or weak?

@interface Book : CBLModel

@property (strong, nonatomic) NSArray* authors;         // Test to-many relationship, is strong or weak???

@property (strong, nonatomic) id<CBLJSONEncoding> toc;  // is this strong or weak?

@end

[Jens Alfke]

On Apr 11, 2014, at 6:50 AM, Ragu Vijaykumar <ra...@scrxpt.com> wrote:

Oh, ok. Does that mean that the NSArray property itself should be held weak, or strong? Also, what about properties that point to NSObjects<CBLJSONEncoding>? should those be held as strong or weak?

Strong. But actually I don’t think the strong/weak annotation will have any effect on the code one way or another. It’s mostly only important for @synthesize’d properties.

—Jens