28
Views
4
Comments
Solved
[Offline Data Sync Patterns] Filter on server side for filtering records using time stamp.
offline-data-sync-patterns
Mobile icon
Forge component by Techcomm Team
Application Type
Mobile

Hello everyone here I we are trying to use offline sync patterns where we are referring to Mobile offline read only Optimized data sync patterns. 

The documentation for offline read only data sync 
https://success.outsystems.com/documentation/11/developing_an_application/use_data/offline/offline_data_sync_patterns/read_only_data_optimized/

We are using this filter to get records who have been changed compared to last sync.

It has the filter mentioned as 

Company.IsActive = True and (Company.ModifiedOn = NullDate() or Company.ModifiedOn >= LastSync)

but the forge component uses  

 Here there is the change in Company.ModifiedOn >= LastSync  or Company.ModifiedOn > LastSync

I think the correct one will be Company.ModifiedOn > LastSync and document needs to be updated because if we use '=' we will also receive records from the last sync also but we only need records after last sync.

Please correct me if I am wrong and which will be the correct answer .

Thanks 
Shlok Agrawal

Solution

Assuming you are using datetime format for lastSync and for ModifiedOn, your precision is a second, a lot can happen inside a single second.

If you would use > instead of >=, then the records you would potentially loose, are those that were created in the same second like the lastSync, but after the LastSync was finished.

Dorine

Hey @Dorine Boudry  

That completely make sense.

Thanks 
Shlok Agrawal

Hi Shlok,

For the most part, I would generally think of both options as interchangeable. You are correct when saying that using '=' you will also -potentially- receive records from the last sync, but with a read-only pattern that isn't necessarily an issue; those records will just get refreshed in the local storage without any changes, and therefore without any expected impact on the app. You could make an argument that for the sake of completeness/fully preventing any missed changes it's better to include those records as well.

The only potential issue would be a longer syncing time due to the additional records, but considering the timestamp should include the "seconds" value in the LastSync DateTime variable, you could reasonably expect that for most cases the amount of records would be too small to really impact the sync's performance. If that number becomes too large (i.e. number of records edited in a single given second), then the full sync mechanism should probably be put into question to not overload the local storage capacity.

Hopefully that helps!

Hey @Francisco Calderón 

I partially found this correct but the second part is still found it unfathomable but it was great to know that my case scenario wasn't a bad idea and can be taken in consideration.

Thanks
Shlok Agrawal 

Solution

Assuming you are using datetime format for lastSync and for ModifiedOn, your precision is a second, a lot can happen inside a single second.

If you would use > instead of >=, then the records you would potentially loose, are those that were created in the same second like the lastSync, but after the LastSync was finished.

Dorine

Hey @Dorine Boudry  

That completely make sense.

Thanks 
Shlok Agrawal

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.