01-27-2023, 08:53 PM
Hi Hendricus,
Thank you for your question about sync and the cache system.
The Cache is designed to capture CRUD calls should they fail or get interrupted due to a poor or missing internet connection. This system works very well for CRUD calls.
At one point we used to cache offline sync calls. But, this caused a fair amount of problems due to the complexity of a sync call. There are deletes and updates with a touch count that made caching syncs problematic.
At one point, we had a partially working model. When using it in the wild (NurseNotes.net), we found that many syncs could be cached. It would make the software feel sluggish processing in this case hundreds of thousands of records multiple times or with different variations. Syncs wheree the cloud was the source made no sense to cache as the communication with the cloud is essential to even understand which files were out of sync. The performance hit was not worth the convenience of trying to cache large amounts of data.
We concluded that it easy enough and more performant to check cdb_result() to see if any calls fail. This may be most important when doing a sync. If a NurseNotes sync fails due to no internet available we can track this and try again when the internet returns.
I reviewed our doc on cdbCache. I see that it lists sync as one of the calls that fit within its pervue. I'll update the doc and remove sync.
Please try checking the result with: if not cdb_result() then [code here to flag syncing for later].
Thank you for your question about sync and the cache system.
The Cache is designed to capture CRUD calls should they fail or get interrupted due to a poor or missing internet connection. This system works very well for CRUD calls.
At one point we used to cache offline sync calls. But, this caused a fair amount of problems due to the complexity of a sync call. There are deletes and updates with a touch count that made caching syncs problematic.
At one point, we had a partially working model. When using it in the wild (NurseNotes.net), we found that many syncs could be cached. It would make the software feel sluggish processing in this case hundreds of thousands of records multiple times or with different variations. Syncs wheree the cloud was the source made no sense to cache as the communication with the cloud is essential to even understand which files were out of sync. The performance hit was not worth the convenience of trying to cache large amounts of data.
We concluded that it easy enough and more performant to check cdb_result() to see if any calls fail. This may be most important when doing a sync. If a NurseNotes sync fails due to no internet available we can track this and try again when the internet returns.
I reviewed our doc on cdbCache. I see that it lists sync as one of the calls that fit within its pervue. I'll update the doc and remove sync.
Please try checking the result with: if not cdb_result() then [code here to flag syncing for later].