We are having issues where the lsid in "lists" of a study is not updating it's link correctly as the study ID changes on Import from another server. I've attached a number of screenshots to follow along with the process in order to re-create the issue.
Attachment 1: QtbiScanAnalyses Schema
-Note the CtScan and PetScan rows and how the Lookup field is "study.CtScans.lsid (ParticipantId)" and "study.PetScans.lsid (ParticipantId)", respectively.
Attachment 2: Export Process
-The export process is shown where everything is exported as a zip file from the source server.
Attachment 3 & 4: New Study Creation
- A new study is created on the destination server as the same name and type as what's on the source server. Permissions are currently selected as my user only.
In the new study "Import Study" is selected and the generated zip file from the source server is selected.
Attachment 1 & 5:
-Back in the schema browser and in the "lists" folder and in the "QtbiScanAnalyses" schema shown in attachment 1 on the destination server, "View Data" is selected.
-In attachment 5, the Ct Scan and Pet Scan fields display a raw URN where the study ID is being displayed as 20 when it should be 5. This indicates that the Lookup links aren't being updated on import and we believe this information should be updated automatically.
Attachment 6:
-To correct this issue, we currently have to go in manually and select the correct scan from the provided drop-down list which is linked to the QtbiScanAnalyses lists object, which would be an extremely arduous task if there were many participants but need to migrate between servers.
Attachment 7: Updated Ct and Pet Scan links
- The links have since been updated **UPDATE** Even though it appears the links have been updated, reviewing the data on our application reveals that the urn stays the same i.e. it is still has the old urn. How would we update this manually as a workaround?
To resolve this issue, would it be possible to have LabKey update these Lookup links automatically? If not, what workaround might there be?
Thank you |
| |
| Jon (LabKey DevOps) responded: |
2017-11-15 00:31 |
Hi Cameron,
I'll have to do some testing on my end, but I think because the lookup is specific to the LSID, that could create some issues when re-establishing lookups since LSIDs end up being unique in each respective LabKey instance.
Just curious, does the list need the actual LSID value to be displayed like in attachment number 5 (without the < > symbols) or does it need to display in the same format as it shows in attachment number 7, repeating the same participantId value?
I think there may be a way to use XML Metadata code instead of the Lookup feature in the UI, but that would depend on your answer to the question above.
Regards,
Jon |
| |
| cmwest3 responded: |
2017-11-16 09:50 |
It's not so much a problem of how it's displayed in LabKey, it's that in our Matlab application, we do use the LSID for object references and retrieval of data from the server. So the fact that the LSID is no longer correct when data is migrated breaks references and our program is unable to find the correct scans as the LSID on the destination server is referencing a scan with the LSID of what was on the source server.. |
| |
| Jon (LabKey DevOps) responded: |
2017-11-17 11:38 |
Hi Cameron,
We are going to continue working with you on this via the ticket that Guy opened earlier.
Regards,
Jon |
| |
|
|
attachment1.PNG
attachment2.PNG
attachment3.PNG
attachment4.PNG
attachment5.PNG
attachment6.png
attachment7.PNG