I am experimenting with a database symbol libraries. I would like to add fields with the current stock, lead times, and price from our internal system to the symbols. Having this information in the KiCAD symbol selection box helps our engineers to make better decisions regarding component selection, and they don’t have to switch between systems and tediously repeat queries.
However, having such “volatile” fields in the database library forces the users to constantly update symbols in the schematic, even when the underlying symbol drawing hasn’t changed. Or say it otherwise - when the user wants to update the symbols, KiCAD prompts them to update all symbols in schematic. As all symbols in the DB library have a change in these volatile fields. In such a case, the user has no idea what they are updating and they struggle to find what has changed so they can check the schematic.
Is there a way to tell KiCAD to ignore changes in certain fields when updating the symbols?
Well, it depends on the structure of your db, if you expose that data in the view that is used by KiCad i don’t think that much can be done.
do you have control of the db? are you using the odbc interface?
i’ve seen in your other thread that you expose the price, so when the price changes on the db, KiCad sees that the component in the library has changed.
I’d change this strategy if i were you.
Remove all rapidly changing parameters from the db view exposed to KC and provide the HW designers with a separate way to access this data, not using kicad.
That kinda defeats the point. They already can do that, but the overhead of switching tools, looking up new components, adds a significant overhead. Having all the metadata in KiCAD increases the productivity by a lot.
There was some discussion about this in WIP HTTP Library v2 Spec (#21278) · Issues · KiCad / KiCad Source Code / kicad · GitLab talking about revamping the HTTP library spec. Right now my suggestion is that there be a separate API that can fetch part detail data, which could include volatile data, that would only be used in the chooser and wouldn’t actually add fields to the symbol.
Not really. You’re looking for a technical solution from KiCad, but this needs a process/social solution.
One possibilty is to follow a strict versioning rule where database updates never make a breaking change to a symbol, only create a new corrected version. Old versions could be marked with a “DEPRECATED” field.