[ome-devel] Plates and Wells

[josh.moore at gmx.de]

Hi, hi.

Bernhard Voigt writes:
 > >        plate = PlateI( old_plate.id, False )
 > 
 > Ah yes, I understand. The approach with the creation of the complete
 > graph worked out. Though, there are still questions remaining and new
 > occuring ;-)
 > 
 > First, is it always necessary to create the links between objects from
 > both ends?
 >         # create list of well objects
 >         wells = self.createWells(cols, rows)
 >         # link plate to wells
 >         map(lambda w: w.setPlate(plate), wells)
 >         plate.setWells(wells)
 >         plate = self.update.saveAndReturnObject(plate)

As background, for each Hibernate collection, one or the other side
"owns" the collection. In unordered collections (most of them) the
holder of the collection owns the collection. But in ordered
collections, the member of the collection owns the collection because
it has to keep up with its index. Hibernate obeys the owning side of
the collection with respect to collection membership, but it uses both
sides for transitivity. So, if Hibernate can find an object in your
graph which has a null that it shouldn't then it will complain, even
if the linkage was done on the one side where it had to be done.

Now, in practice, this doesn't help you much. It still means you have
to make sure both sides are in sync. But what we've tried to do is add
methods which know about this and keep things clean. Here for example
you could use: plate.addWell( well ) for each well. In Beta3.x, the
fields were still accessible because Ice did not provide any way to
hide them. In Beta4 we have hidden these fields to prevent this sort
of problem.

 > I had to set the well's plate, otherwise there was an exception of a
 > Null ref object (the plate). If I'd left out the plate.setWells call,
 > the wells wouldn't be stored.
 > 
 > Second, how to get the wells of an not fully loaded plate object:
 > plate = omero.model.PlateI(someId) # or a query without a join to wells
 > plate.getWellLinks() # does not exist

You'll either have to reload the pixels or add a "join fetch" to your
query. 

 > Well, my guess is that it's probably better to use the Pojos service
 > at this point, but I'm stuck again:
 > pojos = session.getPojosService()
 > pojos.loadContainerHierarchy(omero.model.Plate, [plate.etId().val], None)
 > >>> ValueError: invalid value for argument 1 in operation `loadContainerHierarchy'

The ValueError is because the first argument in blitz is a string
rather than a class, since Ice doesn't have the java.lang.Class
type. This goes for all methods which take a Class in the ome.api
interfaces.

After that, however, you'll run into IPojos not supporting the screen
types. I'll let Jean-Marie fill you in on what insight is doing at the
moment.

 > Thanks again! I appreciate your help! Bernhard

No problem.
~Josh.