Bug #4512
closed
missing entries with multiple copies of the same KAR file in a single repository
Added by Oliver Soong about 15 years ago.
Updated almost 15 years ago.
Description
Things don't seem to work right if I have multiple copies of the same KAR file in a single local repository. I think this is related to only one entry for an LSID being allowed in a repository.
If I make a file system copy of the KAR file, only one copy (the oldest?) will show up in Kepler, which could be reasonable if potentially confusing and inconvenient. I presume this is because the KAR files have identical LSIDs.
However, if I open the KAR in Kepler and Save Archive to create a copy, that copy will show up in Kepler, will appear to be empty (lacking XML and ROML entries), but can be opened. The original remains as before. I think this is because the KAR files have different LSIDs, but the XML and ROML files have the same.
Maybe this is as intended, but it's certainly confusing because the KARs look empty and the folder/KAR listing does not accurately reflect the file system structure.
If i'm imagining this correctly, it would be the same as having any other "components" show up multiple times in the component tree (like when they have multiple semantic types). Except for this case we're talking about the same XML workflow showing under multiple KAR parents. That seems reasonable.
now that i've seen this...it's very confusing indeed!
I think it's absolutely fine to have the "same" (LSID matches) KAREntries show for every KAR that contains them.
With the new Library changes, having two different KARS with the same LSIDs works fine now.
As for having multiple identical KARS in the local repositories (i.e. the KAR LSIDs are the same) this is a structural flaw of the database desing. Because the primary key of the KARS_CACHED table is the KAR LSID there is no way to keep track of multiple copies of the same KAR at the moment. During the cache synchronization any identical KARS are just skipped.
This could be fixed by making the primary key of the KARS_CACHED table an autoincremented integer instead of the KAR LSID. This would change the KAR_CONTENTS table as well since it has a foreign key to the KAR LSID in the KARS_CACHED table. Some code changes would be needed as well in order to properly handle identical KARS.
It certainly wouldn't be too terribly impossible to fix this but may take a couple days of time.
I should clarify the first statement in my previous comment.
Two different KARs (i.e. each KAR has a different KAR LSID) that contain the same contents (i.e. KAREntries that have the same LSID) works fine now with the latest Library changes.
The primary key used for the KARS_CACHED table has been changed to be the full File path for the KAR. So you can now have multiple identical KAR files in the component library after revision 22083
Original Bugzilla ID was 4512
Also available in: Atom
PDF