[ome-devel] Remote API update question

[Ilya Goldberg]

On Sep 23, 2004, at 4:05 AM, Zachary Pincus wrote:

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

Changing the container the feature belongs to - a feature in this case, 
is the same as changing the image a feature belongs to, but I see your 
point about changing references (STs can have references to other STs).

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

I think this is done for convenience.  The Perl API is set up this way 
because sometimes you've got the object already, or you want to just 
chain the references together (i.e. object->reference()->something()).  
Other times you just have the id and don't want to bother loading the 
object it refers to.  The DTO setup closely mirrors the perl API, so 
its present there as well.

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

That I don't know.  Maybe DOug can shed some light.
-Ilya


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