[ome-devel] Remote API update question

[Douglas Creager]

Fantastic questions.  I've been digging up some answers, and you helped 
me find another bug.  (Not the one you put in bugzilla, but a different 
one.)

> 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
> }d
> and call updateObject.

> (1) Why are there two possible methods?

Ilya's right, this is a side-effect of how in Perl, you can say 
$feature->image() or $feature->image_id() -- one loads the referent 
object from the DB, the other just returns its ID.

This means that on update, you can put either into the data hash.  This 
also means that if you put "image_id" into your fields specification, 
you'll get the ID of the reference back.  If you put "image" in, you'll 
get a sub-hash with the data filled in for the referent object.

In the Java code, however, there aren't any accessor methods defined 
which will read the "*_id" fields, so it doesn't help you any to ask 
for them.

> (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'.

It does, but it shouldn't.  This is a side effect of the bug that I 
found while investigating this.  I wrote a test which sends back 
something like,

{
   'image': 1,
   'tag': 'NEW:94',
   'id': 78
}

In this example, I'm trying to set the tag of the feature to the string 
"NEW:94", which should have nothing to do with an object reference.  
(It just happens to look like one.)  However, the parsing code on the 
Perl side tries to follow reference strings like this indiscriminately, 
regardless of whether or not it appears in a reference field.

So, with the current buggy code, you could indeed say "image_id => 
'NEW:1'", and it would work.  But this should be incorrect, and I'm 
going to try and fix this today.  If you put 'NEW:1' into the tag 
field, it should treat that as a string, not a reference.  Ditto for 
image_id; the database layer will just send that value down to the 
database, and you would probably get a Postgres error saying "hey 
that's not a number!".

This bug also affects the first example.  With the buggy code, you 
would be able to put either the reference or the ID number into either 
field when updating.  With the soon-to-be-fixed code, you would only be 
able to put the reference in to the "image" field.  Both "image" and 
"image_id" would accept the ID number.

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

This is a legacy from an older version of the code.  Before, the DTO 
translation code was using that second field to do some type-checking 
and to verify that the referent object existed.  This turned out to be 
unnecessary and slow, since the database layer can catch most of those 
errors itself, so we took it out.  Now it's ignored, and at some point, 
should be removed.


--doug

------------------------------------------
Douglas Creager <dcreager at alum.mit.edu>
Visiting Scholar, MIT Dept. of Biology
77 Mass Ave, Rm 68-371, Cambridge MA 02139
M: +1 617/501-8340
W: +1 617/452-2955