search

binarybucks / ospreyapp

The open source Mac XMPP messenger with class
Other
35 stars 5 forks source link

Occasional CoreData mergeconflicts between gui and framework Mocs #15

Closed binarybucks closed 12 years ago

binarybucks commented 12 years ago

On presence changes there are still merge conflicts between the ManagedObjectContext held by the GUI and the updated one managed by the XMPPFramework. Investigate this, as status updates don't get through to the GUI.

binarybucks commented 12 years ago

Apparently not fixed

binarybucks commented 12 years ago

Occurs when the main thread updates the user object (e.g) increasing unread count before the roster storage receives e.g. a status update. In this moment the roster storage tries to save the changes but is unaware of the modifications done by the main thread. therefore the merge often fails there, but the other way around is also possible. As conflicts should only occur on a per-object basis but not on a per attribute basis a TrumpMergePolicy for both ManagedObjectContexts could fix it. Probably the implications to this should be tested, or the *- (void)willSaveManagedObjectContext * method of the roster storage could be used to make the storage moc aware of changes before trying to merge in the first place.

binarybucks commented 12 years ago

I've been able to engineer around that problem. It basically involves that all write operations are redirected to a custom subclass of the RosterStorage, that dispatches a block of code to the storage_queue where the value is set in the moc of the storage. The storage moc is then saved and propagates the written changes back to the main thread's moc from where it is displayed in the interface.

Basically like injecting an idea directly into the head of the one you'd like to communicate with instead of holding an actual conversation.

This has some other implications I've yet to fix and I'm no sure how this will impact performance. Until I hear back from the Issues I've opened, this is probably the best fix for now.

binarybucks commented 12 years ago

Implemented a fix that merges changes on the main thread. This works, however the storage is not designed to persist between launches, let alone storing data that is not fetched from the server. For the sake of stability and maintainability the ChatController will undergo a mayor refactoring to store its data elsewhere. It has quite a lot of awkward code in it anyway.

binarybucks commented 12 years ago

ChatController is undergoing a mayor rewrite and getting it's own persistent storage that is independent from the XMPPFramework's roster storage. This way we can use the vanilla XMPPFramework the way it's meant to be.