[news.eclipse.tools.emf] Re: Finding an CDOObject based on its intrinsic

[Jasper <jasper.noid@xxxxxxxxx>]

Eike,

CDOResource.getURIFragment(EObject) saves the day :-) I guess I should 
have used this all along (even when using an XMIResource), but I was 
manually retrieving the intrinsic ID and using just that...

As for the CDOID's, I understand the idea, but as much as possible I 
want my front-end to be able to work with both CDOResources and 
XMIResources.

Thanks,
Jasper.


Eike Stepper wrote:
> Jasper schrieb:
> > Using an XMIResource, I can look up an object based on its intrinsic 
> > ID, by calling Resource.getEObject(String uriFragment).
> >
> > If I try the same with a CDOResourceImpl, that fails because, as I've 
> > discovered, CDO uses CDOID's to encode the object's CDOID.Type...
> Yes, internally CDO always uses CDOIDs to identify objects. They are 
> guaranteed to be unique ina whole repository (as opposed to only a 
> resource). You can think of it as an opaque token that is valid only in 
> the associated session (you even can't compare them between sessions). 
> You can use it in any view of the session: getObject(CDOID).
>
> > Does this mean that CDO does not honor the intrinsic ID's declared in 
> > the model? Or if it does, how can one find an EObject based on the 
> > intrinsic ID?
> I don't think that CDOResource honors *intrinsic* IDs. But if the CDO 
> native apporach, i.e. CDOView.getObject(CDOID), doesn't suit your needs 
> there should now (HEAD) be the possibility to call 
> CDOResource.getURIFragment(EObject) to receive a fragment that you can 
> use with CDOResource.getEObject(String). The fragment will possibly not 
> contain the value of the ID attribute of your model but rather an 
> encoded CDOID.
>
> Maybe the URI gurus want to add something?
>
> Cheers
> /Eike