Fix sorting: update cached part stock quantity if a mismatch with db is found

[gyohng]

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_stock is called, which updates the current board database with the new stock values.

[chmorgan]

when would this condition occur? When the database is updated while the plugin is open, without closing and reopening the plugin?

[gyohng]

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]

[gyohng]

Rebased to the main branch. Please consider merging.

[Bouni]

I'm on vacation but will be back on Monday. Then I look into it

[Bouni]

I think the get_stock method is no longer around so having set_stock is useless.
We should stop of saving the stock value to the project db and drop that field as we get the stock dircetly from the parts db every time we populate the footprint list.

Thoughts? @gyohng

[Bouni]

I just realized that we have the stock in the project db so that we can abuse the database for sorting the parts list 🤦🏽‍♂️

This is far from ideal, ideas how we could get sorting better than writing "usless data" into the project db?

[gyohng]

What do you think about populate_footprint_list calling get_part_details to retrieve stock from the main db?

We could also decorate get_part_details with @lru_cache with a cache size of 100000 (large enough to cover almost any BOM, and small enough to prevent memory overflows). Things get accessed from the main database anyway, so once it's called, it'll cache the data, and repeated calls to the same function will just return a cached value.

The download logic can call get_part_details.cache_clear() to reset this cache.

Here's more info:
https://www.geeksforgeeks.org/python-functools-lru_cache/

[Bouni]

We already do that: https://github.com/Bouni/kicad-jlcpcb-tools/blob/main/mainwindow.py#L608

I don't think a cache is necessary, as the search is quite fast (I have not tested this with huge projects but I asume that < 1000 parts is the most likely case).
A cache would bring additional complexity and would not benefit the average user.

I did a few test and found out that ther's a bug in the sorting anyway, but even when I fix the sorting the sort by stock does not work as expected and I don't know why, all other columns wor as expected ...

[gyohng]

Can you submit what you have, I'll check if I can chase the stock sorting

[Bouni]

@gyohng Not much yet but I made a PR for it: #517