…UpdateObjectsFromRepresentations:...) not returning a BOOL, as per convention
…ss, failure queue configurations Signed-off-by: Mattt Thompson <firstname.lastname@example.org>
…cancels any requests with the same method to the same path Signed-off-by: Mattt Thompson <email@example.com>
This reverts commit fd4bd15.
Signed-off-by: Mattt Thompson <firstname.lastname@example.org>
…ration Signed-off-by: Mattt Thompson <email@example.com>
… to updateBackingObject:withAttributeAndRelationshipValuesFromManagedObject:
…ing fetch request
…ManagedObject: method`: 1. Avoided crash that can occur if a related object is currently waiting on a network request before obtaining a permanentID. The fix checks to see if an objectID is not temporary before adding to backingRelationshipObjects. 2. Fixed apparent typo that was attempting to find the objectID for the backing object of the source entity in the relationship. This only works if it checks for the destination entity of the relationship. This bug wouldn't be noticed if the relationship was between objects of the same entity, but it was causing objects to never get mapped in my project.
The original instance of NSSaveChangesRequest was passed to both `AFIncrementalStoreContextWillSaveRemoteValues` and `AFIncrementalStoreContextDidSaveRemoteValues`. The probleme here was that CoreData removes the objects from the sets referenced in the original request as they are saved. This means that from a notification handler for `AFIncrementalStoreContextDidSaveRemoteValues` you are provided with an `NSSaveChangesRequest`instane whose sets are either empty or nil, leaving you unable to get a reference on the managed objects. This is fixed here by creating a new NSSaveChangesRequest with copies of the original sets.
Fixed what I'm 90% sure is a typo. You've set `objectID` to nil, so `objectID.entity.name` will also be nil. I'm pretty sure this should be `entity.name`. I noticed this while reading through the code trying to understand how it deals with object ids, so I can't attest to a problem caused by this or if this change will break anything. Hope it's helpful, tho!
…entEvent in order to get correct values Only sending values for keys with changes in update request