[Loris-dev] Imaging visits in front-end but no UploadIDs in the database
Nicolas Brossard
nicolasbrossard.mni at gmail.com
Wed Apr 22 10:10:19 EDT 2020
Hi Alfredo,
I was told you were given access to MCIN's loris-mri channel. Let me know
if you can login successfully.
Nicolas
On Wed, Apr 22, 2020 at 8:45 AM Morales Pinzon, Alfredo <
AMORALESPINZON at bwh.harvard.edu> wrote:
> Hi Nicolas,
>
> Thank you for your answer. I will prepare some screenshots before our
> meeting. What slack group should I join?
>
> Best,
> Alfredo.
>
> On Apr 21, 2020, at 9:48 AM, Nicolas Brossard <
> nicolasbrossard.mni at gmail.com> wrote:
>
> External Email - Use Caution
>
> Hi Alfredo,
>
> When you say that you can still see those visits, I assume that you are
> saying that they are still listed on the time point list page for a given
> candidate even though you were not expecting them to be. Is that correct?
> And you are also saying that there is still a clickable 'Yes' in the
> 'Imaging Scan Done' column for that visit that leads nowhere (i.e broken
> link), right? Just trying to make sure I understand the observed behaviour.
>
> I have been very unsuccessful running both Zoom and slack phone call on my
> computer. My laptop has has some kind of hardware problem that makes it
> crash very often when I run video intensive softwares like these (it tends
> to shutdown after 5-10 mins. or so, as I have often experienced during the
> remote LORIS meetings....) We could talk via slack (no video) if you like.
> Let me know what you think is best.
>
>
> Cheers,
> Nicolas
>
>
> On Mon, Apr 20, 2020 at 3:55 PM Morales Pinzon, Alfredo <
> AMORALESPINZON at bwh.harvard.edu> wrote:
>
>> Hi Nicolas,
>>
>> I change the Scan_Done value from ‘Y’ to ’N’ but I still can see these
>> visits and links, which seem to be broken links, in the front-end. Any
>> ideas? We can arrange a Zoom call if this helps us to figure things out.
>>
>> Best,
>> Alfredo.
>>
>> On Apr 16, 2020, at 9:05 AM, Nicolas Brossard <
>> nicolasbrossard.mni at gmail.com> wrote:
>>
>> External Email - Use Caution
>>
>> Hi Alfredo,
>>
>> If none of the INSERT statements have a session ID of 845, then that
>> session was not related in any way to the uploads you deleted.
>> Consequently, I think that the behaviour of the delete script is totally
>> unrelated to the fact that session 845 has scan_done = 'Y' even though it
>> is not tied to any archive. When you start a visit, you have to specify
>> whether a scan was done or not and the system will not immediately "force"
>> you to upload scans if you indicated that a scan was done. It is thus
>> entirely possible that:
>>
>> 1. Session 845 was started and the user who started it indicated that a
>> scan was done.
>> 2. No scans were uploaded afterwards for that session....
>>
>> I personally think this behaviour is not desirable and the Scan_done flag
>> should only be set to 'Yes' if the session is tied to an existing archive.
>> If you also agree, you can just identify the sessions that do not fill this
>> requirement and set their Scan_Done flag to 'No'.
>>
>> Hope that help!
>>
>>
>> Best,
>> Nicolas
>>
>>
>> On Thu, Apr 16, 2020 at 12:04 AM Morales Pinzon, Alfredo <
>> AMORALESPINZON at bwh.harvard.edu> wrote:
>>
>>> Hi Nicolas,
>>>
>>> I checked the INSERT statements but no one has a SessionID set to 845.
>>>
>>> Also, are you sure you did not manually delete records from mri_upload
>>> after the delete script was run?
>>>
>>>
>>> Yes, I’ve only used the script. However, I recall that during the
>>> insertion of this study I had issues with the insertion of the images, for
>>> instance I had errors in the middle of the pipeline.
>>>
>>> Let me know if a call can be helpful to figure this out faster.
>>>
>>> Best,
>>> Alfredo.
>>>
>>> On Apr 15, 2020, at 3:42 PM, Nicolas Brossard <
>>> nicolasbrossard.mni at gmail.com> wrote:
>>>
>>> External Email - Use Caution
>>>
>>> Hi Alfredo,
>>>
>>> Yep, all clear. Tables mri_upload and tarchive both have a column
>>> SessionID. You said you did not find in your backup files an UPDATE
>>> statement for session 845. Can you check in your backup files the INSERT
>>> statements for tables mri_upload and tarchive? Do any of these statements
>>> have a SessionID set to 845?
>>>
>>> Also, are you sure you did not manually delete records from mri_upload
>>> after the delete script was run?
>>>
>>>
>>> Best,
>>> Nicolas
>>>
>>> On Wed, Apr 15, 2020 at 3:32 PM Morales Pinzon, Alfredo <
>>> AMORALESPINZON at bwh.harvard.edu> wrote:
>>>
>>>> Hi Nicolas,
>>>>
>>>> Apologies for not being clear in my last email. I meant to say that
>>>> after removing 3200 upload ids and didn’t find the session 845 in any of
>>>> the backup SQL generated files. I have multiple back up files as I removed
>>>> the 3200 ids one by one. Is it clear now?
>>>>
>>>> Best,
>>>> Alfredo.
>>>>
>>>> On Apr 15, 2020, at 2:17 PM, Nicolas Brossard <
>>>> nicolasbrossard.mni at gmail.com> wrote:
>>>>
>>>> External Email - Use Caution
>>>>
>>>> Hi Alfredo,
>>>>
>>>> So what you are saying is that the script deleted a record in table
>>>> mri_upload with uploadid = 3200 but there was no corresponding UPDATE
>>>> session statement? In your previous email you were referring to a session
>>>> with ID 845 that had scan_done set to 'Y' even though there were no
>>>> archives associated to it. Was the mri_upload with uploadid 3200 tied to
>>>> session 845? Are you able to see in the backup file all the mri_uploads
>>>> tied to session 845 that were deleted?
>>>>
>>>>
>>>> Nicolas
>>>>
>>>> On Wed, Apr 15, 2020 at 12:51 PM Morales Pinzon, Alfredo <
>>>> AMORALESPINZON at bwh.harvard.edu> wrote:
>>>>
>>>>> Hi Nicolas,
>>>>>
>>>>> I checked the records, for the 3200 deleted uploadId, and the
>>>>> sessionID was not in there. Also, the UPDATE statement was issues in the
>>>>> same table. Here is an example of INSERT and UPDATE commands in the SQL
>>>>> file:
>>>>>
>>>>> ===
>>>>> INSERT INTO `mri_upload` VALUES (9,'lorisadmin\n','2017-11-28
>>>>> 16:30:47',’/ABC/AAB21935_880779_m00.tar.gz','/tmp/ImagingUpload-16-30-jIjf1G',1,0,'AAB21935_880779_m00',8,8,6,
>>>>> 4,1,1,'N');
>>>>> UPDATE session s SET Scan_done = 'Y' WHERE s.ID IN (4) AND (SELECT
>>>>> COUNT(*) FROM mri_upload m WHERE m.SessionID=s.ID) > 0;
>>>>> ===
>>>>>
>>>>> Maybe the insertion process didn’t finish properly but the state of
>>>>> the database was updated? As you can see this images were uploaded in 2017
>>>>> using LORIS v17.0.0 or v18.0.0. Let me know if you have more suggestions on
>>>>> what to check and how we can solve this.
>>>>>
>>>>> Best,
>>>>> Alfredo.
>>>>>
>>>>> On Apr 13, 2020, at 8:37 PM, Nicolas Brossard <
>>>>> nicolasbrossard.mni at gmail.com> wrote:
>>>>>
>>>>> External Email - Use Caution
>>>>>
>>>>> Hi Alfredo,
>>>>>
>>>>> I am curious to see the actual records that the delete script removed
>>>>> from your mri_upload table. Since the delete script backs up what it
>>>>> deletes, you can have a look inside the backup file it created. By default,
>>>>> this file is named imaging_upload_backup.tar.gz. Inside, you'll find an SQL
>>>>> file that should contain all the entries in mri_upload that were deleted.
>>>>> Can you check if all of them have a sessionID set to 845 (they should)? Can
>>>>> you also check in the same file the UPDATE statement that was issued on the
>>>>> session table? We'll start with these checks first.
>>>>>
>>>>>
>>>>> Best,
>>>>> Nicolas
>>>>>
>>>>>
>>>>> On Mon, Apr 13, 2020 at 8:16 PM Morales Pinzon, Alfredo <
>>>>> AMORALESPINZON at bwh.harvard.edu> wrote:
>>>>>
>>>>>> Dear LorisDev Team,
>>>>>>
>>>>>> I recently removed all the UploadIDs from a study using the script “
>>>>>> delete_imaging_upload.pl”. However, in the front-end I can see some imaging
>>>>>> visits for some candidates of the study.
>>>>>>
>>>>>> Here is an example for one visit:
>>>>>>
>>>>>> Here is the imaging session for one the Candidates with the issue:
>>>>>> ===
>>>>>> select * from session where CandID in (450030) \G;
>>>>>> *************************** 1. row ***************************
>>>>>> ID: 845
>>>>>> CandID: 450030
>>>>>> CenterID: 60
>>>>>> VisitNo: 1
>>>>>> Visit_label: m00
>>>>>> SubprojectID: 2
>>>>>> Submitted: N
>>>>>> Current_stage: Not Started
>>>>>> Date_stage_change: NULL
>>>>>> Screening: NULL
>>>>>> Date_screening: NULL
>>>>>> Visit: NULL
>>>>>> Date_visit: NULL
>>>>>> Approval: NULL
>>>>>> Date_approval: NULL
>>>>>> Active: Y
>>>>>> Date_active: 2017-11-10
>>>>>> RegisteredBy: 5216-ICR_dataman
>>>>>> UserID: 5216-ICR_dataman
>>>>>> Date_registered: 2017-11-10
>>>>>> Testdate: 2017-11-30 11:07:25
>>>>>> Hardcopy_request: -
>>>>>> BVLQCStatus: NULL
>>>>>> BVLQCType: NULL
>>>>>> BVLQCExclusion: NULL
>>>>>> QCd: NULL
>>>>>> Scan_done: Y
>>>>>> MRIQCStatus:
>>>>>> MRIQCPending: N
>>>>>> MRIQCFirstChangeTime: NULL
>>>>>> MRIQCLastChangeTime: NULL
>>>>>> MRICaveat: false
>>>>>> ===
>>>>>>
>>>>>> However, there is no TarchiveID associated with the session id in the
>>>>>> mri_upload table
>>>>>> ===
>>>>>> select TarchiveID from mri_upload where SessionID=845 \G;
>>>>>> Empty set (0.00 sec)
>>>>>> ===
>>>>>>
>>>>>> Any ideas on how can I fix this.
>>>>>>
>>>>>> Thank you in advance for your help.
>>>>>>
>>>>>> Regards,
>>>>>> Alfredo.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Loris-dev mailing list
>>>>>> Loris-dev at bic.mni.mcgill.ca
>>>>>> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>> The information in this e-mail is intended only for the person to whom
>>>> it is
>>>> addressed. If you believe this e-mail was sent to you in error and the
>>>> e-mail
>>>> contains patient information, please contact the Partners Compliance
>>>> HelpLine at
>>>> http://www.partners.org/complianceline . If the e-mail was sent to you
>>>> in error
>>>> but does not contain patient information, please contact the sender and
>>>> properly
>>>> dispose of the e-mail.
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20200422/d7f71c99/attachment-0001.html>
More information about the Loris-dev
mailing list