3lvis / datafilter Goto Github PK

Hi again.

The only crash I really care about now is the last one in DATAFilter. From my observation, it happens when the primary keys are not unique (e.g. when the JSON contains multiple primary keys of equal values).

While I agree that it should not really happen if everything is correctly set up, it can't be guaranteed that the output from JSON is valid.

I think in this case, the error could be easily caught (if changes.count != remoteObjectIDs.count on line 42 in DATAFilter.m) and probably just throw an error.

I'm pretty busy right now, but I can try to find some time for a pull request if needed.

3lvis/Sync#224

Current master still makes heavily use of ObjC types and methods. It's probably better to minimise this.

@3lvis I can work on this if you haven't started with it yet.

Hey @3lvis!

I'm using Sync in a project and have an ordered relationship in my Core Data model. Previously, Sync had been handling this correctly and the objects were mapped to my Core Data ordered set in the same order they were in the JSON. After updating to the latest Sync, however, I noticed the objects were no longer in order. It appears that the issue is with DATAFilter 0.8.3. After reverting to 0.8.2, it works again as expected.

As mentioned in #24 (comment) it looks like we can't bridge DATAFilterOperation so the tests will have to be migrated to Swift (Mirrored in my fork: FrancisBehnen#1)

(not sure why this would happen but ¯_(ツ)_/¯ ) #12

If there is a type mismatch for the identifier in what is in the JSON from what is in the NSManagedObject definition, DATAFilter will fail to see that the objects are identical and will delete and recreate it.

For example, if such JSON is returned (if localKey is remoteID and remoteKey is remoteID):

[
  {
    "id": 30,
    ...
  }
]

And in the NSManagedObject definition, remoteID is of type string and has the value "30", what I described above will happen (Because in the JSON, the identifier will be of type NSNumber and in the NSManagedObject of type NSString)

The method responsible for this seems to be [+DATAFilter changes:inEntityNamed:localKey:remoteKey:context:predicate:inserted:updated:], on the line [intersection intersectSet:[NSSet setWithArray:fetchedObjectIDs]];
The NSSet will use the method isEqual and determines that a NSNumber can't be equal to a NSString (In my example)

I can submit a pull request that fixes the issue by always converting all identifiers (remote and local) to NSString prior to doing the intersection (using [-NSObject description]. What do you think?

Right now predicate only filters items in Core Data, not in the array, you would have to do that manually. But it would be great if this was also supported.

We may want to consider doing something similar to this because, as far as I understand, we also break dependent projects their support for Objective-C