Fix sorting: update cached part stock quantity if a mismatch with db is found #447
Conversation
…se the cached field is used for sorting directly.
| part[5] = detail[0][1] | ||
| if part[5] != str(detail[0][1]): | ||
| part[5] = str(detail[0][1]) | ||
| self.store.set_stock(part[0], detail[0][1]) |
There was a problem hiding this comment.
when would this condition occur? When the database is updated while the plugin is open, without closing and reopening the plugin?
There was a problem hiding this comment.
It will occur persistently after updating a database while having some projects with LCSC components filled from before the update. Reopening the plugin doesn't help. self.store is project-bound and does not explicitly sync its stock quantity value with the database at all. There's just one path where it does - and that's when you use a part selector - and never afterwards. This fix is meant to address it. The condition is there not to call set_stock always, which works through sqlite.
If this code is not there, the sorting logic does not use the data from detail and only considers the non-overridden old once cached and never updated data inside part[5]
This patch corrects a sorting issue in the application where the GUI displayed the correct stock quantities but used outdated cached values for sorting operations.
The fix targets the populate_footprint_list method and involves a condition that checks if the cached stock value (part[5]) in the GUI matches the most recent stock quantity from the database (detail[0][1]). If a mismatch is detected, the cached value is updated to the current database value, and also
set_stockis called, which updates the current board database with the new stock values.