[tigerstripe-dev] RE: Annotations Conversation

["John Worrell (jworrell)" <jworrell@xxxxxxxxx>]

Hi Yuri,

That's great!

Thanks,

JohnW

-----Original Message-----
From: Yuri Strot [mailto:yuri@xxxxxxxxx] 
Sent: 11 July 2008 10:02
To: John Worrell (jworrell)
Cc: Andrey Platov; Eric Dillon (erdillon); Tigerstripe developers list
Subject: Re: Annotations Conversation


Hi John,

thanks a lot for your detailed description of the problem and you are
right - correct way is start change tracking after writing to database.
So, I've fixed it and I also agree with the immutable id, but I'll start
with it after current GMF tasks and TAF API changes.

--
Thanks,
Yuri

----- Original Message -----
From: John Worrell (jworrell) <jworrell@xxxxxxxxx>
To: Yuri Strot <yuri@xxxxxxxxx>
Cc: Andrey Platov <andrey@xxxxxxxxx>, Eric Dillon (erdillon)
<erdillon@xxxxxxxxx>, Tigerstripe developers list
<tigerstripe-dev@xxxxxxxxxxx>
Sent: Thu, 10 Jul 2008 17:58:32 +0700 (NOVST)
Subject: Annotations Conversation

Hi Yuri,
 
Many thanks for your help earlier this morning in pointing out that I
need to keep the Annotation object I create in order that any changes I
make to the content can be saved back - that is, it is not correct for
me to hold the content alone and to look later in the AnnotationManager
for the Annotation object that wraps the content.
 
So, I tried holding the Annotation object and saving that, but this
gives me a NullPointerException in  AnnotationStorage.save(Annotation a)
because there is no matching ChangeRecorder in the changes Map. I have
debuggedthis and I find that the reason for this lies in the way in
which the id is assigned to an Annotation instance... That is, in
AnnotationStorage.add(Annotation a) we have the code:
 
addToList(annotation, annotation.getUri()); // add to list for URI
trackChanges(annotation);                        // create
ChangeRecorder and put in changes Map - id is null at this point
database.write(annotation);                       // assign an id to the
Annotation and write to DB
fireAnnotationAdded(annotation);
 
the crucial point is that if the id is null the hash-code is computed
using an algorithm in EObject and not from the id, but when I go back
and pass my Annotation into the save(...) method ithas an id and so a
different hash-code is computed... which means I can never match my
Annotation to ind the ChangeRcorder.
 
So, what I have done as a temporary measure is to swap the order of the
trachChanges(...)database.write(...) and this seems to work. However, I
think the correct thing to do is to assign an id to the Annotation at
the point of creation, and ideally to make that id immutable/read-only.
 
What do you think? Have I mis-interpreted?
 
Thanks again,
 
JohnW
 
 	
John Worrell
Technical Leader

jworrell@xxxxxxxxx
Phone: +44 208824 9410
Mobile: +44 7789 922290


Cisco Systems Limited
250 Longwater Avenue
Reading
RG2 6GB
United Kingdom
Cisco home page <http://www.cisco.com/global/UK/> 



 	
 	
  Think before you print.	
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.