Opened 9 years ago

Closed 8 years ago

#270 closed defect (fixed)

edit profiles cannot be found in database

Reported by: demeler Owned by: dzollars
Priority: normal Milestone: 1.1
Component: ultrascan3 Version:
Keywords: review Cc:

Description

I made a new us3 install on a VM (Win XP) and set the program up to work off the database. When trying to generate a report from a run in the database I realized that the report program only works from disk, so it naturally couldn't find anything. I thought I may be able to get the run onto the VM's disk by simply downloading it with us_convert and resaving. That part worked. Next, I wanted to edit the run and apply the prior edits and save them locally. When I tried to do that, the edit program could not find the prior edits in the database. Clearly, other programs like 2DSA can find the edits in the DB, so they must be there. This suggests that there is a bug in the edit program that cannot find prior editing records in the DB when DB is selected. I think we should have some way to retrieve editing records from the DB back down to disk. The logical place to do that would be in the editing program.

Attachments (3)

vm-copy.png (204.6 KB) - added by demeler 9 years ago.
screenshot of Windows XP VM with error message
cauma-osman-demo.png (150.6 KB) - added by gegorbet 9 years ago.
osman-demo2.png (122.7 KB) - added by demeler 9 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 follow-up: Changed 9 years ago by gegorbet

My own tests indicate that prior edits can be found in the DB. I could do so both on Unix and Windows.

Further tests are needed to better define the cases under which this defect exists.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 9 years ago by demeler

Replying to gegorbet:

Further tests are needed to better define the cases under which this defect exists.

I believe us_edit only looks on disk for edits, and doesn't follow the DB/disk selection to look for prior edits. I haven't checked the code but that seems to be the most likely reason. When saving an edit, it should be written both to disk and to DB, when reading an edit, it should be taken from where the user sets the DB/disk selection tab to.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 9 years ago by gegorbet

Replying to demeler:

Replying to gegorbet:

Further tests are needed to better define the cases under which this defect exists.

I believe us_edit only looks on disk for edits, and doesn't follow the DB/disk selection to look for prior edits. I haven't checked the code but that seems to be the most likely reason. When saving an edit, it should be written both to disk and to DB, when reading an edit, it should be taken from where the user sets the DB/disk selection tab to.

That is not what I see. On both Unix and Windows, when I load from DB and click Apply Prior Edits, the dialog opened is specifically a DB dialog with edits in the DB. Please specify the DB and AUC under which you think edits are hidden from us_edit

comment:4 in reply to: ↑ 3 Changed 9 years ago by demeler

Replying to gegorbet:

That is not what I see. On both Unix and Windows, when I load from DB and click Apply Prior Edits, the dialog opened is specifically a DB dialog with edits in the DB. Please specify the DB and AUC under which you think edits are hidden from us_edit

I am using the uslims3_CAUMA instance, and the "osman-demo" 2/B/230 triple under XP, check the attached image.

Changed 9 years ago by demeler

screenshot of Windows XP VM with error message

Changed 9 years ago by gegorbet

comment:5 follow-up: Changed 9 years ago by gegorbet

If you run manage_data (or any analysis program), it indicates that, indeed, there are no edits in the DB for the osman-demo run ID.

See attached cauma-osman-demo image.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 9 years ago by demeler

Replying to gegorbet:

If you run manage_data (or any analysis program), it indicates that, indeed, there are no edits in the DB for the osman-demo run ID.

See attached cauma-osman-demo image.

Now I am completely baffled. Before I sent the last e-mail, I was able to run a 2DSA analysis on this dataset! Clearly, an edit profile WAS AVAILABLE then. Now, the run doesn't even show up when I try to load it again under 2DSA or vHW. What happened? Somewhere, somehow, the edit profile got obviously deleted from the database. If you look at attachment 3 you can see there are report items available for a van Holde - Weischet analysis, which clearly must have required the presence of the editing profile, so what is going on, and why is this info lost now? Without the editing profile the TI and RI noise files, which were ALSO available, are useless or orphaned in the database. Have they been deleted as well? If so, there is a serious flaw somewhere in how the database gets handled that must be found and fixed. Take a look at osman-demo2.png attached. I hope there is a logical explanation on how this happened.

Changed 9 years ago by demeler

comment:7 in reply to: ↑ 6 ; follow-ups: Changed 9 years ago by gegorbet

Replying to demeler:

Replying to gegorbet:

If you run manage_data (or any analysis program), it indicates that, indeed, there are no edits in the DB for the osman-demo run ID.

See attached cauma-osman-demo image.

Now I am completely baffled. Before I sent the last e-mail, I was able to run a 2DSA analysis on this dataset! Clearly, an edit profile WAS AVAILABLE then. Now, the run doesn't even show up when I try to load it again under 2DSA or vHW. What happened? Somewhere, somehow, the edit profile got obviously deleted from the database. If you look at attachment 3 you can see there are report items available for a van Holde - Weischet analysis, which clearly must have required the presence of the editing profile, so what is going on, and why is this info lost now? Without the editing profile the TI and RI noise files, which were ALSO available, are useless or orphaned in the database. Have they been deleted as well? If so, there is a serious flaw somewhere in how the database gets handled that must be found and fixed. Take a look at osman-demo2.png attached. I hope there is a logical explanation on how this happened.

Actually, the fact that vHW was run and reports exist only clearly shows that an edit existed. It does not necessarily mean that the edit and its models and noises existed in the DB. I suggest logging unto the same local machine where vHW was run and running us_manage_data to see if the edit(s), model(s), and noises exist locally. If so, they can be uploaded to the DB.

comment:8 in reply to: ↑ 7 Changed 9 years ago by demeler

Replying to gegorbet:

Actually, the fact that vHW was run and reports exist only clearly shows that an edit existed. It does not necessarily mean that the edit and its models and noises existed in the DB. I suggest logging unto the same local machine where vHW was run and running us_manage_data to see if the edit(s), model(s), and noises exist locally. If so, they can be uploaded to the DB.

They do not exist. I never edited any data on this installation. What I did was to check out the windows version Dan compiled under XP. I never uploaded any raw data to this computer, and instead I tried to manage data already existing in the database. The first thing I tried was to analyze the previously existing data osman-demo in the database with 2DSA and vHW. That worked fine. When I ran the editing program, I was trying to load "Previous Edits" which is when it could not find any edits. Consequentially, one obvious thing to check would be if the edit program somehow made a "DELETE" call to the stored procedures or if there is any procedure that can delete or overwrite existing edited data. My hunch is the error is in the editing program.

We may be able to reproduce this error. I found a copy of the editing and model records on my local disk, where it was probably originally edited. I will attempt to re-upload the edits to the database and see if I can repeat the error.

comment:9 Changed 9 years ago by demeler

Another issue that comes up that under Linux I cannot re-load these data from the database. I keep getting the error:

There were not files of the form *.auc
found in the specified directory.

Yet, under windows I can load the data fine.

This happens under us_convert when trying to load the run osman-demo from the database (no local copy exists). What causes this error? This would probably be best addressed by Dan?

comment:10 in reply to: ↑ 7 Changed 9 years ago by demeler

Replying to gegorbet:

Actually, the fact that vHW was run and reports exist only clearly shows that an edit existed. It does not necessarily mean that the edit and its models and noises existed in the DB. I suggest logging unto the same local machine where vHW was run and running us_manage_data to see if the edit(s), model(s), and noises exist locally. If so, they can be uploaded to the DB.

To be clear, the edits MUST have existed in the DB, because I never edited data on that new install I made, I grabbed data directly from the db for 2DSA analysis, without prior editings, and that worked.

comment:11 Changed 9 years ago by dzollars

  • Keywords review added
  • Status changed from new to assigned

With further testing we determined that if the user clicks on the "save" button in us_convert, all the edit profiles, models and noise files are deleted. In other words, when us_convert saves an experiment it starts over.

From the standpoint of us_convert, this is most likely the desired behavior. If it is writing auc files to the database, then the assumption has to be that they are new or different than what you have in there already. This would invalidate any edit profiles, models and noise files associated with them anyway. And even if the auc files are the same but the solution or the rotor is different, any data associated with the old experiment is invalid too.

However, it seems like a pretty natural thing to click on the save button there, not realizing the consequences. Starting over may even be what the user wants to do or should do there. So I have left the behavior in us_convert the same, but added a couple of dialogs informing the user of what will happen and allowing him to cancel.

comment:12 Changed 8 years ago by dzollars

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.