Realm-cocoa: Update notification of inverse relationship modification is not fired if predicate is still satisfactory

Created on 7 Nov 2016  路  9Comments  路  Source: realm/realm-cocoa

Goals

Goals continue to be the same as described in #3853. Realm 1.0.2 fixed inverse relationship notifications, but there is still an issue with not called notification block after entries are modified BUT still satisfy specified predicate.

Expected Results

It is expected that even though predicate is still satisfactory notification is fired because UI could be representing that particular property and needs to be redrawn.

PS. if that is done by design would be good to know that.

Actual Results

Actual results are shown in demo project.
https://github.com/viktorasl/Realm-RLMLinkingObjects/blob/master/Realm-RLMLinkingObjects/ViewController.m

Steps to Reproduce

If predicate filters objects which fooIntProperty is between 1 and 10 and object's fooIntProperty is changed from 1 to 8 (second button) notification is not fired. Notification is only fired if object no longer satisfy predicate (first button, changing fooIntProperty from 1 to 12).

Version of Realm and Tooling

Realm version: 2.0.3 (I believe from 1.0.2)

Xcode version: 8.1

iOS/OSX version: 9.0 and above

Dependency manager + version: Cocoapods 1.1.1

O-Community Pipeline-On-Hold T-Bug

Most helpful comment

@tgoyne ok thanks for the update.

In the meantime I have worked around this by adding a lastModified property to Feed and then when making a change on FeedItem I update last modified using the inverse relationship.

self.feed.lastModified = [NSDate date];

Not that great, but it fires a modification change in the collection notification which is what I was after.

All 9 comments

@tgoyne, can you speak to whether the observed behavior is expected?

This is a known bug that I'm pretty sure we already have an issue for, but I can't seem to find it.

Could be related to #3885?

Seems so, shortly rephrasing - notifications about modified inverse relationship objects are not fired (only insertions and deletions).

I may have just run into this issue as well. I see that it is still open, is there any update or maybe I've just missed a step?

To give a simplified example.

A Feed object and FeedItem object. Feed has an items RLMArray property.

RLMArray<FeedItem *><FeedItem> *items

I have a collection notification block set up for RLMResults where the query is [Feed objectsWhere:@"ANY items.status > 0"].

Any changes to a FeedItem's status property (such as modifying it from 1 -> 2) will not trigger the notification change block as the overall query results are not impacted by this change. I would've expected this change to fall under a modification as mentioned in the collection docs?

You鈥檙e notified about modifications whenever a property of an object has changed, which was previously part of the collection and is still part of it.

You modify the age property of a Dog belonging to that Person

This makes it possible to discretely control the animations and visual updates made to the content inside your UI, instead of arbitrarily reloading everything each time a notification occurs.

Am I missing something to get this functionality working? The CollectionView's datasource is the RLMResults and I would like to reload an individual CollectionViewCell to reflect the update to the FeedItem's status.

@tgoyne, @jpsim, @bdash or @viktorasl do you know if this was addressed? Possibly in a different "known bug" issue instead that @tgoyne had mentioned?

Probably it would be better if you could attach demo project to illustrate the problem. For me notification about changes of directly linked objects (in your case items) works fine. The problem only occurs with inverse relationship (I made a workaround to avoid inverse relationships). There might be a problem with ANY specifier. But demo project would totally help Realm developers.

Nothing's changed here. Fixing this probably requires first finishing keypath filtering for notifications, as we've had a few people tell us that they're using inverse relationships specifically for this behavior.

@tgoyne ok thanks for the update.

In the meantime I have worked around this by adding a lastModified property to Feed and then when making a change on FeedItem I update last modified using the inverse relationship.

self.feed.lastModified = [NSDate date];

Not that great, but it fires a modification change in the collection notification which is what I was after.

Was this page helpful?
0 / 5 - 0 ratings