Hi Nedzad, I do not believe there is a built-in way to do that at this time - RhoConnect client updates are not atomic from the point of view of your application and what you are seeing is the default behavior; you will have to handle these discrepancies on a case-by-case basis (hint to the Zebra Rho team: adding rollback capability would be a really nice addition, dealing with this scenario in application code is a pain).
How you react to this depends on your application: one possible approach is to let the user know when there is a synchronization problem and not let them perform certain actions until they complete one full sync cycle. You could also leverage bulk sync, which guarantees that all records in a partition will be present (but you may have to change how you deal with client updates locally so as not to lose user data). Another option is to mark your models on the server so that the header row knows how many item rows it should expect and notify the user if there is a mismatch. Keeping track of this is another pain and it can get ugly and complicated very quickly depending on your application.
There must be more ways to deal with this (you could keep track of which rows came from a successful sync cycle and which did not, then delete those manually, but you would also have to make sure to update the changed_values table so that it does not try to delete those rows from the server. It's not clean but it might work).
Hopefully that will get you pointed in the right direction at least.
so, do you know if Rhomobile is planning add atomic stuff to Rhoconnect? Without this, it is going to be killer-effort to take care of this on bad GPRS connectivity. Also, is there some code samples about monitoring one fully sync cycle or taking care of this within the code ?
Thanks for clarfication!
1 of 1 people found this helpful
RhoConnect is inherently asynchronous in its sync behaviour to provide maximum scalability.
Data sent from clients are added to a queue and the server process them in batches, asynchronously.
It's not an easy task to add atomic operation to this kind of architecture and I'm not sure that it can be implemented without a deep re-architecture of what we've.
Javier suggestion to manage this at the application side is currently the best option.
thank you for jumping in. Ok, this is something we have to learn :-). Can you please share some code snippets or examples how to handle this in efficient way so we don't loose time over this?
Thank you again,