[ome-devel] Remote API update question

[Ilya Goldberg]

Hi Zach
On Sep 22, 2004, at 5:53 PM, Zachary Pincus wrote:

> Hello,
>
> I've got a few minor questions about how updating objects with the 
> remote framework works.
>
> Specifically, when you pack up a DTO for update over the wire, there 
> appear to be two ways to specify objects to which that DTO refers.
>
> Say we've got pulled a DTO from over the network for a Feature that 
> looks like so:
>
> {
>   'image': {'id': 2},
>   'tag': 'CELL',
>   'id': 78
> }
>
> Now say we want to change the image to which feature 78 refers to 
> image 1.

Can't really do that.
There are two object hierarchies in play here.  One is the "core" 
hierarchy of Project->Dataset->Image->Feature, the other is the 
vagaries of STs.  Im including STs as an object hierarchy because much 
to our surprise (!) they seem to support a fairly complete inheritance 
model (though some might argue), and we're working on the syntactic 
sugar to make it palpable.  A very important aspect of the STs is where 
they belong in this core hierarchy.  None of the objects in the core 
hierarchy are STs, they can only act as containers for STs.  Perhaps 
its a weakness of the datamodel, but that's how it is for now.  In the 
future, its possible to think of a scenario where the "core" hierarchy 
is represented as STs as well, but that's not how things are now.  
There are numerous complications that arise from this, as you can 
probably imagine.

An ST (by its declaration) can belong to a Dataset, Image or Feature, 
or it can be Global - that's the granularity of the ST.  You can't 
switch the container that the ST instance belongs to, nor can you 
switch its granularity.  Basically once you have an instance of an ST, 
you are locked into its container instance.  You can change its 
contents only as long as it has no assigned MEX.  Once it has a MEX its 
immutable.  This is why we refer to instances of an ST as attributes - 
they are attributes of the container they belong to.  Some containers, 
like features, are described only by their attributes - they are 
abstract.  It is sometimes useful to also think of features as image 
attributes, because unlike the other levels of the core hierarchy, 
images and features are limited to a one-to-many relationship.  This is 
the same pattern as the container-attribute relationship - one to many.

Some of this is hard to enforce in OO-space, and there has been some 
thought to enforcing it at the DB layer (with triggers, for example).  
So far we've counted on "good behavior" in applications to keep this 
aspect of the datamodel consistent.

If you think about what you're proposing actually means physically, its 
an impossibility.  You're saying I found this blob in Image 1, and it 
has all these attributes.  Now, I'm going to take this very same blob 
along with all of its attributes and assign it to Image 2.  It just 
doesn't make sense in terms of the physical reality this represents.

Unless of course, I completely missed your point.

-Ilya




>
> We could do this two ways:
> (a) Change the DTO to look like so:
> {
>   'image': 'REF:Image:1',
>   'tag': 'CELL',
>   'id': 78
> }
> and call updateObject on that DTO, or
>
> (b) Change the DTO to look like so:
> {
>   'image_id': 2,
>   'tag': 'CELL',
>   'id': 78
> }
> and call updateObject.
>
> Several questions:
> (1) Why are there two possible methods?
> (2) If we want to have the DTO refer to a new image, we can make it 
> look like so:
> {
>   'image': 'NEW:1',
>   'tag': 'CELL',
>   'id': 78
> }
> and call updateObjects with a list which contains the new image first, 
> and then this DTO.
> The question is whether this method would work if we set 'image_id' to 
> 'NEW:1' rather than setting 'image'.
> (3) In option (a) above, we need to set the 'image' field to 
> 'REF:Image:1' -- why not 'REF:1'? The fields are strongly-typed, after 
> all. OME knows that it must be a reference to an Image. In fact, if we 
> set 'image' to 'REF:Feature:1' or even 'REF:foobar:1' it works just 
> the same way, with no errors. Is there any reason for this?
>
> Thanks,
>
> Zach Pincus
>
> Department of Biochemistry and Program in Biomedical Informatics
> Stanford University School of Medicine
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>