I have a working sync (both ways) between a server using MSSQL and an iPhone using CoreData.
But I'm having problems when I delete a row on the server and then sync on the client. The client (iPhone) gets the deleted row change, but the data doesn't contain any ID, which means that the client can't find the local row.
When inserting or updating rows on the server, the entire entity is sent to the client and that data contains the ID of the entity/row.
In the toolkit source, file ODataJsonWriter.cs (line 203) it checks if the entity is a tombstone and if so it doesn't send the entity contents. I guess it shouldn't be neccessary as the entity should be deleted. But how can the client know which entity if it doesn't get the content, which includes the ID?
But because the server don't know which field the client needs, shouldn't it send all the entity content anyway? What's the harm, except for bandwidth?
when a row is deleted on the server, the server only keeps track of the ID of that row and some metadata that it's tombstoned.
when a row is deleted, there is no entity data for that row apart from the tombstone record, so there is really no entity record to send other than the tombstone information.
So the problem remains. How can the client identify the deleted row when it doesn't get enough information?
I have tried the iPhone sample in the toolkit but it crashes when it tries to find the row, because it's missing the neccessary information.
The only thing I can find that could be useful in the metadata is the uri field. The uri contains the ID (guid) of the item. But that means that I have to parse the uri. Seems more like a workaround than a solution.
I solved it by making a copy of the method WebUtil.ParseIdStringAndPopulateKeyFields() and changed it to parse and return the ID from the idString.
I then added the ID as new metadata in ODataJsonWriter where it writes the tombstone element by calling my new method.
Now my iPhone client receives the entity ID when a row is deleted on the server and can easily find it in CoreData and delete it.
- Edited by DeceptX Tuesday, February 07, 2012 10:45 AM