This is a little long, but hopefully helpful to other folks too. We’ve run into a conceptual issue with the Backendless Data service that probably indicates we just don’t fully understand how Backendless is supposed to be used.
Database cursors are one way to scan through a DB table and do a read-modify-write operation on selected records:
Backendless supports paging operations where one can retrieve a “pageSize” of objects that meeting specific search criteria starting at an “offset”. At this general level of description this is similar to but not necessarily the same as a cursor.
As I mentioned, the advantage of a cursor is that one can scan a table and do read-modify-write operations on selected records. It’s not clear to us that Backendless’s system for paging through a table actually allows that because it’s not clear what “offset” actually means in the Backendless case.
The scenario of concern is that in a page of objects/records that match some search criteria, one or more of the returned records are modified in some way that they would no longer match the search criteria and are written back to the table.
For instance, suppose we search for records matching some criteria with “pageSize = 5” and “offset = 10” (i.e. records at “offset=10” to “offset=14”. Suppose also that in the returned set of records that we modified the third and fourth record (“offset=12” and “offset=13”) so they no longer match the search criteria, but had not modified any records in the first two pages.
If “offset” is somehow based on the pre-modification table contents, than this would essentially match the operation of a cursor. On the other hand, if the Backendless “pageSize” and “offset” properties operate the same as in a SQL RDBMS, the next retrieval starting at “offset=15” would start with a later record (“offset=17” in the unmodified table) than if no records in the page were modified.
Alternatively, we would have to keep track of how many records were modified and adjust the offset value (“offset = 13” rather than “offset=15”) for the next page. This however, in turn assumes that objects/records are always retrieved in the same order, which one can’t assume in an conventional SQL RDBMS. In a SQL RDBMS one has to use the ORDER BY clause and order the records based on the contents of one or more columns, which can affect query performance.
Can you supply a pointer into something in the Backendless docs that explains how one can scan through a Backendless Data table seeking selected records, modifying and writing back only some of those selected records in the way a cursor allows?
Thanks very much.