Open Arekusan01 opened 2 years ago
Ticrob
commented
2 years ago Same issue with numbers of item related to Web library (Qiqqa 82 / W$10). I have moved all my documents from a former web library to a new local library. Cut and paste well done in the new local library. Nevertheless the empty web library still displays the same amount of items and not zero. I have 3 former web libraries and the issue is the same each time. Not a big bug, but still a bug ;)
GerHobbelt
commented
1 year ago 😓 indeed document numbers as reported by Qiqqa (up to and including any v83 test release) do not match user reality.
It seems the largest discrepancy is due to moved/deleted documents still being included in the count (Qiqqa doesn't really destroy those metadata records, but rather flags them as 'deleted' so there's still a chance of recovery when things go horribly wrong any time later on -- your collected metadata is, next to the PDFs themselves, your most valuable data, so deleting it was probably deemed a bad choice back in the day. And I haven't introduced a new counter-opinion about that once Qiqqa became Open Source and I could get my grubby hands on it. 😄
Anyway, an SQLite qeury issue in the codebase I suppose -- with a few caveats.
Thanks for reporting, by the way! 👍 (Apologies for the long silence)
klmckinney
commented
1 year ago I've been thinking of fixing this by adding a "clean database" function which one could call after they are satisfied that no corruption has occurred after the desired move and/or delete item operations had been completed.
@GerHobbelt I think you know the codebase better than anyone. Does that seem a good solution or a bad idea?
Also, everyone is encouraged to share their opinion.
GerHobbelt
commented
1 year ago Hi Kenelm,
It's a bit of an and A and B thing: I'll have to go through the queries in the codebase to correct them to exclude records marked as deleted (A) and like you suggest add the option\command to clean your database(s) in the tools\utilities menu.
The driving thought here is that marking records as deleted, rather than actually erasing them, gives one the option of reverting (undo) -- granted, current qiqqa doesn't offer this as a user command, but the base idea is solid IMO, while erasing a database record is something you can't undo and should therefore be a special "cleanup\vacuum" admin action.
These metadata records don't take up a lot of space, so I'm in favor of git alike behaviour for such stuff: never throwing something away, for that (Deleting) is a unrecoverable action.
Anyway, qiqqa isn't careful enough in it's summarizing (counting) queries so that should be fixed anyway.
I've been away from the c# code for a while, so I'll have to read up to make sure I don't screw anything up ☺️
On Sun, Sep 4, 2022, 16:27 klmckinney @.***> wrote:
I've been thinking of fixing this by adding a "clean database" function which one could call after they are satisfied that no corruption has occurred after the desired move and/or delete item operations had been completed.
@GerHobbelt https://github.com/GerHobbelt I think you know the codebase better than anyone. Does that seem a good solution or a bad idea?
Also, everyone is encouraged to share their opinion.
— Reply to this email directly, view it on GitHub https://github.com/jimmejardine/qiqqa-open-source/issues/374#issuecomment-1236353424, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADCIHVHMKJ3SRTWDS7AAU3V4SWWBANCNFSM5OUMKMOQ . You are receiving this because you were mentioned.Message ID: @.***>
Hey, Thanks for all the work in this great tool! But, I wonder if v82 shows the right number of elements in the lib. Actually I'm cleaning my library and alltough I#m deleting a hugh amout of elements the number in the lib does not sink. and: quigga chrashes with no report or anything. It just closes.
Can anybody please give me further information? Thanks a lot