missing entries with multiple copies of the same KAR file in a single repository
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.
#1 Updated by ben leinfelder over 11 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.
#3 Updated by Aaron Aaron over 11 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.