[ome-users] General questions
igg at nih.gov
Fri Mar 25 03:55:45 GMT 2005
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
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
> 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.
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
More information about the ome-users