[ome-users] General questions

[Ilya Goldberg]

On Mar 24, 2005, at 2:19 PM, Gerald Fontenay wrote:

> Hi there,
>
> FYI, I just installed the latest stable version, 2.4.0, on SUSE Linux 
> 9.1 and it went well after several iterations of dropping the old 2.2 
> ome db and removing files from /opt/OME-IMAGES.  All required packages 
> appear to have been installed from the previous 2.2 install.
>
> My first question is this: how are users expected to be able to use 
> SQL without going through whatever OME interfaces exist? Is this 
> envisaged, at all?

There are ways left over from the days when we had a lot of SQL in the 
code.  The database is normalized with a (for the most part) 
table-per-class arrangement.  There are ways of injecting your own SQL 
and instantiating objects also.  You can use straight SQL, but there 
are a few constraints that are not in the DB which can make make this 
somewhat dicey.  There's no reason why they shouldn't be there, just 
haven't gotten around to it.

> Regarding table creation, I know new database tables are created from 
> semantic type definitions. I'm somewhat fine with that step if  I 
> could be shown an example of m:n relationship that made sense to me. 
> If I look at plates and screens, for example, I see plate ST and 
> screen ST and their respective tables. Now since there is an m:n 
> relationship, so I see plate_screen ST, fine, of course. What I don't 
> see are key references in the database table plate_screen_map to 
> plates and screens. I find this a bit disorienting. Are such 
> constraints maintained in the software infrastructure? This puts in 
> doubt being able to do inserts, e.g..

The STs declare references to other STs.  Unfortunately, the FK 
constraints for these aren't put in when the tables are created.  
Currently, STs can only declare has-one relationships (a simple 
reference to another ST, or a foreign key).  It is possible to use the 
API to dereference inferred relationships even though they are not 
declared in the STs and not set as FK constraints in the DB.  For 
example:
$factory->findObjects 
('OME::Image',ImagePlateList.Plate.PlateScreenList.Screen.Name => 
'Foo')
The convention is to use 'List' after the ST name when using an 
inferred relation.  The Plate ST has no PlateScreen field, but 
PlateScreen has a reference to Plate, so the fact that Plate must have 
many PlateScreen(s) is inferred.

The Plate/Screen/PlateScreen thing has me a bit stymied I must admit.  
Either a plate has a reference to screen, or a PlateScreen has a 
reference to both plates and screens to act as a map.  I'm not at all 
sure why Plate has a reference to Screen when we're using a map to 
define a many-to-many relationship.

Maybe we should have a discussion on the developer list why this is 
defined this way.

With regards to inserts, the module_execution_id column in the data 
tables needs a not-null constraint, and this is likely to get one soon. 
  The FK constraints on ST references should probably go in at the same 
time.

>
> My second question is this: where can  I find an example  of  java  
> OME API code that would, say, allow me to query and update the 
> database on some m:n relationship of semantic types?

Maybe somebody else can pick this up.

>
>
> Thanks,
> Gerald

Ilya

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