Bug #4512
closedmissing entries with multiple copies of the same KAR file in a single repository
0%
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.
Related issues
Updated by ben leinfelder over 14 years ago
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.
Updated by ben leinfelder over 14 years ago
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.
Updated by Aaron Aaron over 14 years ago
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.
Updated by Aaron Aaron over 14 years ago
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.
Updated by Aaron Aaron over 14 years ago
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