on 11-21-2015 11:00 PM
I am working on a Cordova/SMP Kapsel based application using the OData Offline plugin.
The application is designed to be in "offline" mode all the time, except when the user clicks a sync button, which then executes the flush() and then upon success, then refresh().
All this is working, except I have noticed that after the flush/refresh, the local data objects which had been modified or created still shows up along with the actual data which has been pulled from the backend, so there appear to be duplicates. We noticed the issue because it doesn't seem to occur for all entities.
We have been able to correct the issue for some entities by changing the return (the backend is SAP NW GW) to return the fully updated object in the return for the POST/CREATE request. This seems to have the resolved the issue for some entities but not all.
The offline store correctly removes the object from the request queue (so it does not get processed any more) but it does not remove the flushed data like it is supposed to. I assume there is some sort of mapping that gets done internally that allows it to figure out which record to remove after a successful flush, but can't seem to figure it out.
Any ideas?
Hello Dan,
We have the same problem, do you have any work around about that?
Thank you!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It looks like the basic rule of thumb is that you can't modify the key fields during the transaction. For example you can post data to the backend that has key fields either blank or populated. During the transaction (CREATE/UPDATE/MERGE,etc) when the data is returned in the response, anything can be changed by the backend except populated key fields. If the backend overwrites blank fields, that is fine.
In our case, we were trying to generate temporary offline key values, which get overwritten on the POST to the oData (SAP NWGW) server with the real backend generated unique key values. It looks as though the better way to do this would be to create a separate non-key field which could store the temporary offline value (so the UI can use it), so that the key values don't change during the transaction.
Let me know if you need more clarification...
Thank you Dan for your very useful information and approach.
Our situation is a bit special, we want to flush (POST/PUT) new records and then have those records deleted from the local offline store (we also use temporary ids). We don´t know what response should the backend give to those requests in order to achieve this.
Here you have a post created by me :
The same logic applies, even in our case. When you POST/PUT something to the OData server, the http response payload must contain the new or updated record (http://www.odata.org/getting-started/basic-tutorial/#create). In this response payload, the backend can add key values that did not exist in the POST/PUT, but if it changes one (id# for example) the SMP Offline store does not clear. I assume this is because the offline store odata provider is tracking these by the key values.
Thank you for your useful explanation.
I would like to ask you, what is your implementation to fix this POST problem? we have tried to make the POST request omitting the "ID", and also with a "fake" ID (and returning the new ID within the same object in both cases) and none of these worked.
PUT is working because IDs already exist in the database.
Thank you in advance.
To get it to clear, we had to make sure how we handled these 2 things:
- The request could only include key values in the POST if they were not going to change in the response payload. If omitted or not included we had to include a blank value (null or undefined did not seem to work consistently). This seemed to be true often for all values not just key values. We had to include blank values to get it to clear.
- The response had to include the correctly populated key values which were updated by the post.
For example:
if request "key1"="123" and response "key1"="123", then OK
if request "key1"="" and response "key1"="123", then OK
if request "key1"=null or undefined and response "key1"="123" then NOT OK
if request "key1"="123" and response "key1"="124" then NOT OK
Try to play around with this and see if you can get it to clear properly.
User | Count |
---|---|
96 | |
11 | |
11 | |
10 | |
9 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.