[ome-devel] Database Issues: FK, UNIQUE, and such

[Joshua Moore]

> You're working with an old DB.  The current release does not have an 
> experimenter reference in imageAnnotation.  

Ok. I'll try to test out the code generation on the DB_UPDATES branch as
soon as possible and repost the results.


> > II. FOREIGN KEYS
...
> Personally, I don't like this loosey-goosey usage of foreign key 
> constraints.  The data model has to be reflected in the DB schema.

Certainly don't want any loose gooses (regardless of the connotation of
"loose"), but there's also something to be said for guaranteeing data
integrity at the db level. Couldn't the FKs _sensibly_ be represented at the
data model level?


> There are a number of chicken-egg issues with doing this on a fresh DB 
> install, so this isn't in this branch yet.  My current thinking is to 
> do this in a separate call to the DB delegate 

Sounds like how pg_dump does things.

> This should cover all the missing FKs above.

splendid.


> > III. One-to-One

> We don't currently support explicit "has-one" relationships using 
> references.  So for now at least, an image can in fact have multiple
dimensions.

Back to data integrity, does it make sense for an image to have multiple
dimensions, and how to I deal with that programmatically?

  if (dimensions.length > 1) throw new OopsException()



> > VI. Miscellany

>If Java assumes that ...

As I said, it was more of a question for the Java guys. If the class
...shoola.env.rnd.data.DataSink is the "proper" way to do the mapping, I'm
happy. I just didn't want to be repeating this in my code.


> >  * Should the maps have a UNIQUE constraint on both fields.
> 
> Explicit many-to-many relationships (maps) are not supported in STs.  
> This could in-fact be done transparently by saying that an ST 
> consisting of only references gets a UNIQUE constraint on all its 
> fields.


Sounds awfully implementation-ly. What about whether they /should/ have
them? And again, how do I take care of it programmatically if there's the
possibility that there will be multiple maps (to get all implementation-ly
myself)?


> >  * Projects and datasets are many-many. CGs and Cats are 1-Many. 
> > Screens and
> > plates as well? What is/will be the rule-of-thumb for these (and 
> > future)
> > containers?
> 
> What did you have in mind?

What I had in mind was, roughly, that there seems to be such a parallel
drawn between PDI and CGCI in many (public) arena. If we ignore that PDI is
somehow class based and CGCI is ST based, one might expect that they obey
the same hierarchy constructs. Certainly not a must, it's just what I've
come to expect from how we've talked about the various hierarchies. 

-J

-- 
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl