Ticket #255 (closed defect: worksforme)

Opened 3 years ago

Last modified 3 years ago

entity tokens should be stable

Reported by: robert@… Owned by: business@…
Priority: major Milestone: 0.6.5
Component: Core Functionality Version:
Keywords: Cc: m.s.vanvliet@…
Product: Operating system:
URL: Hardware:

Description

The studyToken, sampleToken and assayToken can be changed by the user. This results in errors when a (e.g.) sample is renamed. A module that has data for that sample, doesn't know the sample is renamed, but only knows that one sample is removed, and another one is added. That way, the module doesn't know what to do with the data connected to it.

Example:

GSCF has samples A1, A2 and A3. A module has data for all 3 samples. Now, the user renames sample A2 to A4 (for some reason). The module now sees that the study has samples A1, A3 and A4. He will conclude that A2 has been removed and A4 has been added.

This can be avoided by creating stable tokens that will never change. This could be the id of an entity, but might also be another value, as long as it is stable for the lifetime of the object.

Even when this situation won't happen often, it is still important to avoid the problem anyway.

Change History

Changed 3 years ago by robert@…

  • owner changed from work@… to robert@…
  • status changed from new to assigned

Changed 3 years ago by robert@…

The solution for this is to create separate studyUUID, sampleUUID and assayUUID fields (since the assayToken is now a templatefield, which might raise issues when changed).

These fields will be populated with a UUID, using the java.util.UUID class. These tokens will be used for communication with the modules. The communication will still be the same as it is now, except that gscf will use another token internally.

When modules are already in use now, they might have trouble with the new tokens.

Changed 3 years ago by business@…

This looks good to me. I will try to get this through to all the modules being built.

Changed 3 years ago by robert@…

  • owner changed from robert@… to business@…
  • cc m.s.vanvliet@… added

This changes was made in r1440. I've tested the rest controller and gscf/assay/showByToken and gscf/study/showByToken, and they work perfectly (although with new tokens). I couldn't find any other parts of GSCF that would be touched by this change.

Would you test whether it works OK?

Changed 3 years ago by robert@…

As of r1442, the notification for modules of changes in a study also uses this new token

Changed 3 years ago by work@…

Robert, have you tested if these domain changes' database changes are automatically performed by Grails, or if DatabaseUpgrade?.groovy needs to be extended in order to facilitate the changes?

Changed 3 years ago by robert@…

@Jeroen: At my local installation the database changes are done automatically (I've only added three columns). Could you look into the ci-database whether the fields Study.studyUUID, Sample.sampleUUID and Assay.assayUUID are present?

Changed 3 years ago by work@…

Hey Robert,

You could have done that yourself at:  http://ci.nmcdsp.org/dbUtil

However, I had a look instead... Study.studyUUID is present as well as Sample.sampleUUID (both have lowercase column names in PostgreSQL).

However, the values are all empty but I see that should be filled automatically on every _giveUUID()_ call...

Cheers, Jeroen

Changed 3 years ago by work@…

  • milestone set to 0.7

Changed 3 years ago by business@…

  • milestone changed from 0.7 to 0.6.4

Changed 3 years ago by business@…

  • status changed from assigned to closed
  • resolution set to worksforme

This looks good, implemented now in metabolomics module, still to do in transcriptomics / CTD and SAM (both are being worked on).

I wonder why in the domain model UUID is nullable/blank? Because otherwise we run into problems with early persistance / save()?

Changed 3 years ago by robert@…

The field is nullable, since the field was added after the database was used. If the field would not be nullable, the database upgrade would have raised errors.

However, this is handled in the giveUUID() method. That method generates a UUID if it doesn't exist.

Note: See TracTickets for help on using tickets.