attempt to delete and reload the same index path about realmresultscontroller

[Carpemeid]

If I comment "query.cars.appendContentsOf(carsObjects)" then everything seems to be ok with tableView updates/inserts/delete.

If I leave it uncommented then as I can conclude some additional notifications are sent to the RealmResultsController and it tries to delete and reload at the same index path or something like that.

But now I also encountered 'attempt to delete row 0 from section 0, but there are only 0 sections before the update'. Which makes no sense as at that point the db has 0 rows because it's the first app launch. If I preload the db with at least 1 record, then this error also does not occur.

And that becomes spooky. Maybe the models inside the results controller are not updated yet(background thread) when it responds the number of rows to the tableView and in the same time tries to already do some updates on the tableView. I really can't find any real clue about what's happening behind.

After more debugging:
This 'attempt to delete row 0 from section 0, but there are..' occurs because for some reasons it inserts that row, then inserts another, then updates that first row and then ends tableView updates.

And the tableView complains that it is illegal to insert and then "delete". In this case I suppose that update for the table view means = delete + insert. Thus the delete from the tableView point of view is illegal as at that point of time there were no objects yet, so you cannot delete it.

Supposal : the ResultsTableViewController should not insert and update the same row in the same begin/end updates session especially if it is about the initial state when there were no objects before that begin update.

[Carpemeid]

Tried to listen to Realm Notifications and I this is what I've got in the notifications

NSConcreteNotification 0x15df0ee0 {name = CarObject-/cars/renault-megane-coupe}

Unfortunately it does not show what operation was made on object, in order to debug the ResultsController behaviour.

[polqf]

Hi @Carpemeid ,
I am going to dive into this issue right now, has happened a few times in our app also.

Thanks for the detailed information.
I'll keep you up to date

[polqf]

Hi @Carpemeid,
This issue has (theoretically) been solved, and will be included in the 0.4.1 version.

I want to comment that this issue is not completely related with RRC, is a bad usage of it.

The source of the problem occurs when you try to do different actions to the same object inside a write transaction. Such as:

realm.write {
    let object = // retrieve object with primaryKeyValue = 123
    let anotherObject = ObjectSubclass()
    anotherObject.primaryKeyValue = 123
    realm.deleteNotified(object)
    realm.addNotified(object)
}

What #67 is going to do, is to prevent a crash on the endUpdates, by handling these problem. But this is not going to ensure that the data is as expected. There is a restriction applied, the stablished order of importance is DELETE>UPDATE>ADD. So, if you add and remove the same object, it is going to be treated as a deletion.

Appart from that, we added a Log telling what has happened. If you want to take have more information about what is the duplicate, just set a symbolic breakpoint RealmResultsController.warnDuplicated

Also, you were complaining about because subscribing to notifications was sending the object. Now it is sending a RealmChange object that has all you need.

That said, feel free to reopen the issue if you that happens to you when we release 0.4.1

[Carpemeid]

But the only thing I was doing in the realm transactions was adding with update (theoretically inside the transaction I have only that operation.. of course somewhere in the back Realm may delete/add/update in order to make the update work as expected).

And I cannot avoid using [add with update] because I cannot know if my db will contain the objects that are going to be "updated" unless I do an additional reading transaction and compare all that stuff manually. But doing an additional reading for that does not seam a good solution.

[polqf]

@Carpemeid I understand, don't get me wrong. It is not that I am saying that doing this is wrong. My message was not in that direction, sorry about it.

My point was, the way we defined the usage of the RRC, was this one, and that was what we expected the users to use it. There's another thing here, we did not completely think about this scenario. We talked about this, and agreed that we are going to implement, in the future, a timeline based behaviour. That is, the last thing you do, is the one that is going to prevail.

[Carpemeid]

Yep, of course. I understood) just wanted to make sure I got your point.