On Mon, May 25, 2009 at 4:05 PM, Teg <t...@djii.com> wrote: > Hello Sam, > > Paging or scrolling is purely an abstraction you create with the GUI > itself. If you load up 88 titles into memory and your screen display is > 40 lines then you have 3 "pages" in memory and you simply replace a > "page" each time they scroll or page up/down. You seem to be letting > the back end dictate what the GUI does when in fact it's better to > abstract the whole thing so, you can change the back end at will and > not have to change the GUI. For 88 items, I doubt I'd even use a DB. > Nothing beats a flat text file when you have a tiny data set.
I hear you that paging should be frontend logic, normally. The problem is that I have a *DYNAMIC* record set that is constantly changing: The nature of the dataset is that it can grow very quickly early on and at any point after that rows can be deleted through out. It is this last fact that I need the help of the backend to figure out the page. Assume 5 items per page. If there are 88 items in the record set on one call that returns 50 to 55, before the next call, items 3,12, 17, 32, and 42 are all deleted from the record set, Item #55 is now going to be #50. If the front end is simply giving the backend an unique identifier of the item, not the PK, per the recommendations of the ScrollingCursor page, how does the front end learn that it now is getting #50 through #54 rather than #55 through #59? Further, I am assuming this is a problem with paging on any dataset in any database, thus a backend issue :) Sam _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
