| Issue Number | 3580 |
|---|---|
| Summary | Replace doc internal fragment ids issue |
| Created | 2013-01-31 11:19:42 |
| Issue Type | Improvement |
| Submitted By | Osei-Poku, William (NIH/NCI) [C] |
| Assigned To | alan |
| Status | Closed |
| Resolved | 2013-09-03 21:27:10 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.107908 |
BZISSUE::5278
BZDATETIME::2013-01-31 11:19:42
BZCREATOR::William Osei-Poku
BZASSIGNEE::Alan Meyer
BZQACONTACT::William Osei-Poku
A couple of weeks ago we discussed an issue we have with the Replace Doc with New Doc utility and agreed that it will not be possible to match fragment ids from the new doc with ids in the old doc. Upon further investigations, I may not have presented the problem accurately so I am hitting the reset button and will try and describe the problem again below after testing it on Mahler this morning.
The Docs I used to test on Mahler are 734899 and 458088. The problem is that if there are internal summary fragment refs in the new doc, after the replacement is completed, the fragment refs continue to be pr-pended with CDR_ID of the new doc (which is now blocked) so users will need to go through the document and delete all the CDR IDs referring to the new doc. Alternately, users may have to delete references to the new doc before doing the replacement.
Initially, I thought that was a bug in the program but I realized that that is how the internal fragments are created. So, they are carried to the old doc just as they are in the new doc.
So now the question is will it be possible to grammatically:
1. Either remove all references to the new doc CDR_ID during the
replacement process?
2. Or replace the CDR_ID of the new doc with that of the old doc during
replacement?
BZDATETIME::2013-01-31 15:35:11
BZCOMMENTOR::Alan Meyer
BZCOMMENT::1
I understand what needs to be done. I don't think it will be very hard.
I'll give higher priority to the tasks that must be accomplished for the transition to CBIIT hosting of the CDR servers, then work on this among other CDR tasks.
This is in version control and ready for testing.
In order to test this I made a number of changes to the CDR0000744038, a new version of the Adult Primary Liver Cancer Treatment summary. I added a table near the top of the document with a mix of SummaryFragmentRefs, SummaryRefs, SummaryFragmentLinks and SummaryLinks. The targets were either the selfsame document or a new document. I also added a <WillReplace> element that is required for the replacement document to work.
Then I used this document to replace the existing liver cancer Summary, CDR0000062906.
After performing the replacement I checked the table to see that all of the fragment references to 744038 were replaced with references to 62906, and that no other references were affected.
Everything appeared to work.
I did this conservatively, only changing CDR IDs with fragment refs. I did NOT change:
Any occurrences of the CDR ID that are not in a cdr:ref or cdr:href.
Any occurrences in a cdr:ref or cdr:href that do not have a fragment id.
After testing, I used "Replace CWD with Older Version" to restore things as they were.
For testing on DEV, I recommend a similar procedure. Try:
Call up 744038 (or whatever you choose) in XMetal.
Add or modify links as desired.
Save.
Run Replace Doc With New Doc.
Inspect.
Run Replace CWD with Older Version to restore the initial conditions for the older version of the document.
While testing, I also noticed something I didn't like in the existing program. The program reports links that link to the old document that will be overwritten by the new document. It instructs the user to fix these by hand. But it doesn't filter out links that come from itself. In other words if old document X has internal links to document X (i.e., to itself), they are reported as links that need to be fixed up. But of course they don't need fixing up. They're going to be overwritten by the new version of the document.
So I modified the query that supplies that information and made it ignore links from an old document to itself.
Ready for QA on DEV.
The program works great and users are already excited about it. Thank
you!!
There is just a minor issue which is not a result of this modification
because it seems to exist in Production. If there is a leading zero in
the digits that represent the Day of the Date Last Modified (DLM) date
element, it disappears after the replacement, making the document
invalid. For example, if the DLM is 2013-09-09, it will become 2013-09-9
after the replacement. It is a minor issue so if it will take a lot of
time to fix it, don’t bother to fix it.
I fixed the "9" vs "09" problem.
As expected, the change wasn't hard to make. Only one character needed to be changed, but there's a catch. The date last modified is taken from today's date. However today is September 10, so I can't tell for sure that the change actually worked because Sept. 10 is already a two digit date. I know that the modification didn't break the program. It runs and produces 2013-09-10. But I can't test without setting the date differently on the server which, even if the system allows me to do it, might cause CBIIT to get upset with me.
Instead of changing the time I wrote a separate test program just to test the date format change. That worked. Just to be sure however, we should test again on October 1, which will still give us time to fix it if there's a bug. I'll set an alarm to remind me to test it again on that date.
We've tested the fix for the "9" vs "09" problem and can confirm that the problem is gone.
Thanks William. I started to test it on Tuesday but in the rush of getting everything ready for the government shutdown I had to abandon that and didn't get back to it.
Verified on QA.
Verified on Prod.
Elapsed: 0:00:00.001334