Following on to this thread which is now closed, I had a similar question as to why a prefix with the sub-lib name is added in the individual sub-libraries of a db-lib (i.e. dblib:sub-lib/key). My use case is that the key I use for parts is globally unique (an internal part number) within the whole database across sub-libraries. One of my use cases for this is when I move a part from one sub-library to another or (e.g. when making new sub-libs when categories get cluttered), I don’t want to have to update part links in my schematics.
The explanation given in the above linked thread is that this is done based on the contract of db-libs which doesn’t require the key to be unique across sub-libs (which is fair enough). However, HTTP libs which also have sub-libs, do not follow this convention and you just get httplib:key which I suppose is requiring the part name to be unique across all sub-libs. I’m curious how/why the inconsistency between HTTP and DB libs got introduced.
I’m actually in the process of porting from HTTP libs to db-libs right now, and the sublib being in the part name is making it pretty rough to create a script to auto-update existing designs.
Looking for some feedback on if a PR would be accepted for a solution to this. One solution is to have an option in the *.kicad_dbl file to say if keys are unique across all sub-libs which will result in parts getting placed with dblib:key rather that dblis:sub-lib/part. Not sure if that setting would be best global to the whole *.kicad_dbl file, or a per-sub-lib option (I lean the ladder for more flexibility). In the ladder case sub-libs marked for globally unique keys would be placed as dblib:key while ones without it set (the default for backwards compatibility) would be dblib:sub-lib/key. This would be fully backwards compatible and invisible to anyone who doesn’t want to use it, but also give people who do have globally unique keys in their dblib the option to take advantage of that for reasons stated above.