Quote:
Originally Posted by kiwidude
Ummm... what if the user has an edit dialog open at the time that the plugin is ready to update the database? That assumption sounds flawed to me - at least for books that already exist in the database. How can the plugin "assume" modal control when the user may have opened their own modal dialog?
|
Empirically, if the user has the metadata dialog for a book FFDL is downloading open when FFDL finishes (updating the book's metadata), and the user then 'OKs' the metadata dialog, the book will be updated with what the user just changed, possibly overwriting columns FFDL has just populated.
If the user has the metadata dialog for a book Count Pages is counting open when Count Pages finishes, the 'update library' dialog is opened 'underneath' the metadata dialog and can't be accessed until the metadata dialog is closed. Then the user can tell the PI to proceed, possibly overwriting columns that they just set manually.
I don't think either approach is fundamentally incorrect, just different design choices.
However, if you tell me that you know that there can be corruption (not just contradiction of assumptions) if the db changes while the edit metadata dialogs are open (or other PIs run?), I'll bow to your greater experience and stop letting people skip that dialog in FFDL, too.
(I think that may be what you meant by "concurrency and stale data to deal with", but you also could have just meant overwriting data.)