[ome-devel] New Branch for DB Updates - Shoola testing.

[Ilya Goldberg]

Update on testing Shoola 2.4.1-rc1 against the OME_2_4_1_DB_UPDATES 
branch:
The version in the splash screen still says 2.2, BTW.

Data Manager:
	Image and dataset annotations saved OK.
	PDI: Adding Images, Datasets, Images to datasets, and datasets to 
projects all working.
	CGCI:  Adding CGs, and categories to a CG is working, but:
		Adding images to a category does not work.  When clicking "Save", 
error is "Can't update the specified category.".  Details say: "Can't 
retrieve object. Type: Category, Criteria: 
org.openmicroscopy.ds.Criteria at db9199."

Viewer:
	Rendering settings saved OK.

ROI:
	Appears to be working OK.  No apparent way to save the ROI to the DB.  
No errors reported when I made one.

Chain Builder:
	A simple chain constructed and saved properly.

-Ilya



On Jun 2, 2005, at 10:16 PM, Ilya Goldberg wrote:

>
> 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
>>
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>