[ome-devel] Remote API update question

[Zachary Pincus]

Thanks for the discussion of the type model -- this actually clears up 
some other questions I've had. As to my original questions, I think I 
may have proposed a bad example to illustrate them. So let me try to 
re-phrase them with a sensical example:

Say we've pulled a DTO over the network representing Feature 78, which 
belongs to image 1. We realize on further processing that it is 
actually a sub-blob within a larger blob, and thus the parent feature 
should not be null, but should be feature 64, which is another blob in 
image 1. Presumably this is a sensical operation? (If not, just treat 
this as a straw man. This is meant to be a generic question about the 
update machinery of the remote API.)

Anyhow, we've got a DTO that looks like so:

{
   'image': {'id': 1},
   'parent_feature': null,
   'tag': 'CELL',
   'id': 78
}

And we want to update it via the remote API such that the parent 
feature is now ID 64, and the tag is 'GOLGI' or whatever.

We could do this two ways:
(a) Change the DTO to look like so:
{
   'image': 'REF:Image:1',
   'parent_feature': 'REF:Feature:64',
   'tag': 'GOLGI',
   'id': 78
}
and call updateObject on that DTO, or

(b) Change the DTO to look like so:
{
   'image': 'REF:Image:1',
   'parent_feature_id': 64,
   'tag': 'GOLGI',
   'id': 78
}
and call updateObject.

Several questions:
(1) Why are there two possible methods to do this (via the fields 
"parent_feature" or "parent_feature_id")? Is there a reason to prefer 
one over the other in certain cases?
(2) If we want to have the DTO refer to a new parent feature, we can 
make it look like so:
{
   'image': 'REF:Image:1',
   'parent_feature': 'NEW:1',
   'tag': 'GOLGI',
   'id': 78
}
and call updateObjects with a list which contains the new parent 
feature first, and then this DTO. Now my question is whether this would 
work if we set 'parent_feature_id' to 'NEW:1' rather than setting 
'parent_feature' to that value.
(3) In option (a) above, we need to set the 'image' and 
'parent_feature' fields to 'REF:Image:1' and 'REF:Feature:64' 
respectively -- why not 'REF:1' and 'REF:64'? The fields are 
strongly-typed, after all: OME should know which kinds of objects each 
field/column refers to, right? In fact, if we set 'parent_feature' to 
'REF:Image:64' or even 'REF:foobar:64' instead of 'REF:Feature:64' it 
works just the same way, with no errors -- that is, no type checking 
seems to be performed on the middle type value. Is there any reason for 
this?

Thanks,

Zach Pincus

Department of Biochemistry and Program in Biomedical Informatics
Stanford University School of Medicine



On Sep 22, 2004, at 9:14 PM, Ilya Goldberg wrote:

> 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
>>
>