Hello Sam, SC> I take it that there is no solution to my problem?
That's our job isn't it? Designing some solution that works? - Might have a worker thread watching the DB and have it sending notifications to the GUI as deletes and additions were made to the DB so, the display would be updated in real time. - Might design it so, updates to the DB are sent to a table of updates and the worker thread both integrates the updates AND notifies the GUI of the specific update (something like a task queue but, in the DB itself). - if the updates are external, might make the updater update an "update table". So, the worker thread knows what was done without having to scan the whole DB. - If I couldn't do that, I might keep all the rowid's in memory and refresh the rowid list from time to time to find the changes (added and deleted rowids). This is kind of basic to problems like this. It's not that there isn't a solution, there's a 100 different ways to do it. You just have to pick one. The "realtime-ness" of the display will determine the design. In Windows for instance a "grid" never has to be filling in with data, it can re-paint the items dynamically in real time as a result of notifications. I'd probably use a pure virtual list control, worker thread that monitors the DB and gated notifications to the GUI that stalls the worker thread until the notification is processed (since in windows, worker threads can't talk directly to the GUI elements). In that way the GUI remains responsive, only a single thread talks to the DB and the display can be updated in real time. It's how I handle list controls with 500,000+ elements. Then you just pick whether you want it to scroll or page. Monday, May 25, 2009, 5:02:22 PM, you wrote: SC> I understand and agree that things changing in the middle is not SC> ideal. In the situation I am dealing with, things MUST disappear in SC> the middle of the dataset. As far as adding things, it should happen SC> at the end, but that is outside of my control, it all depends on how SC> things are sorted. Normally things will be added to the end of the SC> dataset, though. SC> I take it that there is no solution to my problem? SC> Sam SC> On Mon, May 25, 2009 at 4:53 PM, Teg <t...@djii.com> wrote: >> Hello Sam, >> >> Are you planning on periodically updating the display as the user >> interacts with it? Have items pop in and pop out again as they're >> added or deleted? From your description, the data displayed in the GUI >> will go stale very quickly. I actually have similar logic in my app >> and I always append new things to the bottom so, it doesn't affect the >> current displayed page. Nothing annoys me more than to have items >> dynamically appearing and disappearing while I'm trying to interact >> with a GUI. >> >> >> >> Monday, May 25, 2009, 4:32:56 PM, you wrote: >> >> SC> 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. >> >> SC> I hear you that paging should be frontend logic, normally. The >> SC> problem is that I have a *DYNAMIC* record set that is constantly >> SC> changing: >> >> SC> The nature of the dataset is that it can grow very quickly early on >> SC> and at any point after that rows can be deleted through out. It is >> SC> this last fact that I need the help of the backend to figure out the >> SC> page. >> >> SC> Assume 5 items per page. If there are 88 items in the record set on >> SC> one call that returns 50 to 55, before the next call, items 3,12, 17, >> SC> 32, and 42 are all deleted from the record set, Item #55 is now going >> SC> to be #50. If the front end is simply giving the backend an unique >> SC> identifier of the item, not the PK, per the recommendations of the >> SC> ScrollingCursor page, how does the front end learn that it now is >> SC> getting #50 through #54 rather than #55 through #59? >> >> SC> Further, I am assuming this is a problem with paging on any dataset in >> SC> any database, thus a backend issue :) >> >> SC> Sam >> >> >> >> -- >> Best regards, >> Teg mailto:t...@djii.com >> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> -- Best regards, Teg mailto:t...@djii.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
