However, this doesn’t make much sense to me — on the one hand, why would the default be “by reference”? (when reference is something that can very easily change, including after the part has been carefully placed/laid-out).
But perhaps my most fundamental issue is: why would it be up to the user to deal with something as abstract and mysterious as a “timestamp”? (I know, users of this software are likely engineers … but not necessarily software engineers or engineers with any experience in software development).
Why wouldn’t a footprint be identified by which footprint it is, instead of being identified by its label (which, ehem, can change!) or by some mysterious thing called “timestamp”? Why not assign an internal id acting as “primary key”?
BTW, if the timestamp is the timestamp at creation and is unique (in particular this second part, I’m not sure), then why bother asking the user — just always identify the footprint by its timestamp (am I missing some valid use cases where the timestamp would change?)
Timestamp is what you have called primary key. That mysterious thing is defined and explained in the manual And you are right: the timestamp of a component cannot change.
As there are two options and one of them fits your needs, I see no problem at all.
I am writing this on my android tablet and can not verify at tue moment, but if my memy memory serves me well, “timestamp” is not the default. I had various occasions where a footprint I changed in the schematic didn’t change in the layout until I remembered to select “timestamp”. So it seems like it woud at least make sense to make that the default. Why would I reimport the netlist if there is no change in nets or footprints anyway?
There should be no need to explain that particular detail in the manual or anywhere — by having the option to choose to match by ref or by “unique/internal identifier”, the software is introducing a problem where there was none, and now the manual (and/or the folks here on the forum! :-)) has to explain it.
The basic intuitive view, IMO, is that the user should not need to be aware and specify anything in this particular situation; since the footprint does have a “primary key”, I don’t think it makes sense at all to even have the option to “match by reference”, let alone that option being the default!
The reference is the main identifier in electronic design. The unique identifier is a backup for when you changed the references mid design process. Both identifying systems have their usecases.
By reference allows you to update the schematic symbol from the library without running into trouble matching the symbol to the footprint. By timestamp allows you to run a reannotation while still correctly matching footprints and symbols.
KiCads standard workflow assumes that you do not change references after starting to design the pcb. At least not normally. This is why by reference is the default. (Updated symbols happen more often in that workflow then changes to references)
Can you explain why one would run into trouble matching a symbol to the footprint if you use the option “by timestamp”?
I agree that by reference allows you to do this — what I’d like to see is a case that by reference handles and by timestamp cannot handle. That would justify having an option additional to “by timestamp”
My point is: since the timestamp is a valid/legit “primary key” (that is an assumption/premise on my side, as I was told earlier in this thread that that is the case), then it should always be the underlying identifier. That the user will see the reference as the thing that identifies the element, that’s a different thing: as an example: we think of the name (say, full name) of a person as what identifies that person (in daily life, we never refer to someone by something like their passport ID or social security number or whatever). That doesn’t mean that in a software application (in a database) we should choose the name of a person as the primary key.
It is a bit of legacy behind that. I seem to remember that in the past if you rescued a symbol you got a new timestamp. At least in the current nightly this is not the case. When i get home i will check how it behaves in v5 and in v4.0.6
What this example tells me is that the timestamp is then not a valid primary key, and should not be used as the real identifier of the part. If in your example the part is the same, then an attribute that now takes a different value cannot be its identifier.
The software should keep track of the real identity of an element. So the user changed the transistor from NMOS_DGS to NMOS_DSG; or from Q1 to QIN1… or any other change; it doesn’t matter: it is still the same element; why would the user have to tell the software how to tell that it is the same element? It is the same element, so the software should be able to tell !!
How the software can guess the new symbol I have added to the schematic after having deleted the old one is the same?
Or if I add a symbol and then delete the old one? No matter the order of the actions.
If I delete some symbols and then add some more symbols, how the software guess which one is replacing which one to assign them the same timestamp?
Maybe I didn’t explain that NMOS_DGS and NMOS_DSG are not labels but different components in the library.
If I change NMOS_DGS to NMOS_DSG the software keeps track with the reference.
If I change Q1 to QIN1the software keeps track with the timestamp
Anyway I think this discussion is driving nowhere. I’m not a kicad developer.
And you are right: the timestamp of a component cannot change.