Bug #4633
closedLSID conflicts
0%
Description
Create a workflow and save a KAR (KAR1). Note the LSID. Change the workflow in some recognizable fashion and save a KAR (KAR2). The LSID bumps as expected. Close the workflow and open KAR1. Make a different change (so it's obviously not the workflow in KAR2) and save the KAR (KAR3). Notice that when the workflow reopens, it looks like KAR2 because it is KAR2 down to the MOML in KAR3.
I'm observing this at r22183 right now.
Updated by Aaron Aaron almost 15 years ago
Fixed, lsid updating now recognizes if it is the highest revision in the cache or not. If it isn't then it becomes one higher than the highest revision in the cache.
Updated by Oliver Soong almost 15 years ago
This still seems to occur if I'm not using local repositories.
The crux of the problem is nobody is tracking used revision numbers, as seems to occur with object and instance numbers.
Updated by Aaron Aaron almost 15 years ago
LSIDGeneration and LSID Revision updates are now being recorded. The LSID_GENERATOR table still needs to be moved to the Persistent database when that gets set up. For now the Object IDs and Revisions will come and go as you clean your cache. More logic is needed for recognizing a clean LSID_GENERATOR table and refreshing the AuthNamespace if the table is empty.
soong you're a harsh mistress, hopefully this change doesn't effect performance too terribly!
Updated by Aaron Aaron almost 15 years ago
The logic for querying a new namespace from an Authority in the event that the recorded object IDs and revisions have somehow been lost (deleted most likely, or table data corruption) is now in place. Just need to get the LSID_GENERATOR table into the persistent database and we can close this.
Updated by Aaron Aaron almost 15 years ago
Closing this bug. Opening a new bug (bug 4701) with the one remaining task of moving the LSID_GENERATOR table.