I have no choice but to label this problem a bug. Sure, it could be inaccurate use of the export API, but the documentation suggests otherwise.
I am using rows=x to signal how many rows I want to download. I am using start=x to signal the row from which downloading starts, using a 0-based counter, row 0 being the first row. That seems to work fine when exporting all 400+ bookmarks in quantities of 10 rows, stopping when either a null is returned in the query or that less than 10 rows came back from a query.
Jump ahead to using the API again later to refresh, after more bookmarks have been added. More rows. I use the row count from the previous export (e.g. 499) as my new start row. What Diigo returns is something exported earlier from a lower row.
Specifically, I asked for export with start=499 What I got back was something I exported the day before at row 496
I'd really like to hear from the Diigo programmers on either the nature of a new bug, or an explanation of how to use the export API in a way that prevents this from happening.
I have a new theory. It appears that the explanation for this is that Diigo treats rows as a stack, last one in on top (row 0). That explains why adding a couple of new bookmarks pushed old ones further down. So, my new theory is that I must put in the query sort = updated_at which, I suspect, would sort the rows on update date always giving me (I'm just guessing here; the documentation doesn't suggest otherwise) that last one in will be last one out.
Sorting returns last first. That's not helpful. This becomes an open question: how does one update an export without seeing previously-exported bookmarks?
started by Jack Park on 10 Oct 08
I am using rows=x to signal how many rows I want to download.
I am using start=x to signal the row from which downloading starts, using a 0-based counter, row 0 being the first row. That seems to work fine when exporting all 400+ bookmarks in quantities of 10 rows, stopping when either a null is returned in the query or that less than 10 rows came back from a query.
Jump ahead to using the API again later to refresh, after more bookmarks have been added. More rows. I use the row count from the previous export (e.g. 499) as my new start row. What Diigo returns is something exported earlier from a lower row.
Specifically, I asked for export with start=499
What I got back was something I exported the day before at row 496
I'd really like to hear from the Diigo programmers on either the nature of a new bug, or an explanation of how to use the export API in a way that prevents this from happening.