Quote:
Originally Posted by Lord KiRon
Just to compare try to do the other way around (meaning getting there from the menu). At least with about 30 authors there is no delay there and as davidfor already mentioned its all done in memory anyway, so as programmer I can tell you you do NOT have to rebuild database (which is modified anyway when you delete book) all that you need is to decrement book counter on the author "you are in" in memory and if it's 0 then remove author from "in memory" list displayed.
No interactions with database whatsoever and , unless you have like 10k authors should be without any delay.
I think it's just a bug, someone forgo to call update on that author, that's it.
|
Without access to the code, it is hard to know what is actually happening (and I have no desire to decompile it). But, I wouldn't expect there to be an author object floating around. I would expect that the list is generated as needed by reading through the collection of books. But, if there is an author object, it is, hopefully, returning the count of books in it list rather than the value of a counter. And with that, it is the list not being redrawn rather than the objects behind it not being updated. Then it becomes a question of whether it is a bug or a design decision for performance optimisation. Or a "we'll do that in phase 2". Without access to the code, bug database and design, it's hard to know which.
But, if you think it is a bug, or needs to be changed, report it to Kobo. That is the only way they can know what is important to their users to fix or changed.