Project

General

Profile

Bug #2572

Export KAR can produce several actors with the same lsid

Added by Norbert Podhorszki over 12 years ago. Updated over 11 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
actors
Target version:
Start date:
10/26/2006
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
2572

Description

Start new workflow
Create two composite actors (put something into them)
Export them as KARs (one-by-one into two KARs)
--> they get different lsid in the KAR (e.g. 1 and 2), fine
Modify the first one and export again
--> it gets the second's (last) lsid (2)
Copy/paste any of them, modify the new composite and export it
--> it still gets the last used lsid (2)

New lsid is generated, apparently, if you drag new actors on canvas. Just modifying the existing composites, even copy/paste them does not help.

History

#1 Updated by Chad Berkley about 12 years ago

This is a problem with how we store lsids in the cache. The problem is that the generated kar file does not get cached when it is created (although it could be cached later). If we store the lsid in the database upon kar creation, it will have to get a new lsid when it is inserted into the cache (because there is no way to know that the object being put into the cache is the same as the one that was created earlier since we lose control of it). Another way around this is to ask the user if they wish to get a unique lsid or not.

The heart of this is that we still need a centralized way to keep track of lsids. We are still dependent on the local machine to generate ids, which in no way guarantees they are unique. To really fix a lot of these ID issues, we need a central ID repository (or we need to use library.kepler-project.org as one).

#2 Updated by Chad Berkley over 11 years ago

I fixed this bug by detecting the lsid collision and asking the user if he/she would like to change the id of the component they are importing. This is the best solution I could come up with until we further discuss the topics I brought up in comment #1. I also fixed several other bugs that came up in the process of figuring this out. I think a couple of them are probably responsible for the corrupted cache that we would see every-once-in-a-while.

#3 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 2572

Also available in: Atom PDF