[ome-devel] New Branch for DB Updates

[Ilya Goldberg]

On May 16, 2005, at 12:07 PM, Ilya Goldberg wrote:

> Hi all
> Some of you monitoring the CVS RSS feed may have noticed that I 
> started a branch (OME_2_4_1_DB_UPDATES) to deal with DB updates that 
> have been on deck for a while.  As mentioned before, the proposed 
> updates were these:
>
> 1. Change CONFIGURATION.VALUE to type text (bug 460).
> 2. Change ST FilenamePattern.Basename to text to allow storing comma 
> separated values rather than integer (to get the full basename from 
> several RE 'parts').  Requested by Nico Stuurman to support his 
> filename naming scheme from a Beckman screening scope (Bug 484)
> 3. Add group owner to MODULE_EXECUTIONS, fix bug 469 (attribute 
> ownership inherits from MEX)
> 4. Not NULL constraint on attribute's MEX column (bug 485).
> 5. Not NULL constraint on MEX experimenter column (bug 468).
> 6. ST foreign key constraints for references (PKs already declared) 
> (Bug 486).

#6 added to the list of updates in the OME_2_4_1_DB_UPDATES branch.
This includes adding FK constraints for *ALL* DBObjects that declare a 
class reference (regardless of wether or not they declare a ForeignKey 
SQL option).  The constraints are added after importing a block of STs 
or as the last step of the DB installation.  This adds a lot of new 
constraints to the DB!

Current testing status of the OME_2_4_1_DB_UPDATES branch:
update 2.2.0 -> 2.4.1
update 2.4.0 -> 2.4.1
	both populated, but not very heavily.
fresh install 2.4.1
Functionality tests included import, and a find/trackSpots run using 
the Web UI (+ random gefinger poken in the Web UI).

Had to reorder ST loading during installation, and combine files with 
STs that refer to each other (Group.ome is now in Experimenter.ome and 
Plate.ome is now in Screen.ome).  Needless to say, things are a *lot* 
pickier now, and a *lot* harder to screw up.  Surprisingly, the core 
functionality still works with my limited tests.  Its actually fairly 
amazing that it works at all if you think about it.  We rock!

Note that Java has not been tested at all yet!

> To checkout the branch (its the entire OME CVS module),
> cvs co -r OME_2_4_1_DB_UPDATES OME

If you test (and please do!), you will probably want to backup your 
working DB:
sudo ome admin data backup -q -a pre-2.4.1-backup.tar.bz2
And, you need to run the installer
sudo perl install.pl -y
And to restore your old DB after testing,
sudo ome admin data restore -a pre-2.4.1-backup.tar.bz2

I'll be doing Java testing today and tomorrow.  Please volunteer to 
help with testing!

I know everyone is busy, but these changes make our datamodel rock 
solid and self-protecting from any entry point, including direct DB 
access.  This means that things that modify the DB improperly will now 
break instead of subtly corrupting the DB only to be discovered later.  
This will make things a lot easier to debug, with fewer subtle 
datamodel bugs creeping in.  Its ultimately to everyone's benefit, and 
makes this a much more reliable system.  But we need to make sure that 
we exercise every bit of functionality to expose anything that's 
broken.

-Ilya


>
> -Ilya
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>