Bug #4633
closed
Added by Oliver Soong over 14 years ago.
Updated over 14 years ago.
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.
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.
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.
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!
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.
Closing this bug. Opening a new bug (bug 4701) with the one remaining task of moving the LSID_GENERATOR table.
Original Bugzilla ID was 4633
Also available in: Atom
PDF