|
| Re: [CDO 0.8.0] eDirectResource return always NULL [message #122907 is a reply to message #122904] |
Fri, 23 May 2008 07:01   |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Simon,
I'm not really sure about the expected semantics of eDirectResource and
eInternalResource. The JavaDoc is not very helpful:
/**
* Returns the containing resource, or <code>null</code>.
*/
Resource eResource();
/**
* Returns the containing internal resource, or <code>null</code>.
*/
Resource.Internal eInternalResource();
/**
* Returns the directly containing internal resource, or
<code>null</code>.
*/
Resource.Internal eDirectResource();
As I understand it, there are basically two approaches to determine the
resource of an object:
1) walk up the containment relationship (eContainer) until that is null
(top level object) then return its resource (eDirectResource)
2) A non-top level object has for some reasons directly stored its
resource (eDirectResource), then return it (or null)
eResource() is just a public wrapper for the eInternalResource() which
does 1)
eDirectResource() does 2)
If that's correct, I'd say for most non-top level objects
eDirectResource() would return something (null) different from
eInternalResource() and eResource().
Ed, is that correct?
Can you please explain how these methods relate/differ to/from each other?
In any way a CDOObjectImpl should behave exactly according to the
sematics implied by EObject and InternalEObject. If that is not the
case, please file a Bugzilla.
Cheers
/Eike
Simon McDuff schrieb:
> I tried to complete my automatic persistence mechanism,
>
> I have one case I do not handle and it seems to be because one value in
> BasicEObject that is not set properly. In fact it is never set.
>
> eDirectResource is always null when we use CDO. Did we never want to set it
> ? (when we attach an object and/or when we load an object) ?
>
> Usually it is set when we attach an object to a resource...
>
> Simon
>
>
>
|
|
|
|
|
| Re: [CDO 0.8.0] eDirectResource return always NULL [message #618155 is a reply to message #122904] |
Fri, 23 May 2008 07:01 |
|
Hi Simon,
I'm not really sure about the expected semantics of eDirectResource and
eInternalResource. The JavaDoc is not very helpful:
/**
* Returns the containing resource, or <code>null</code>.
*/
Resource eResource();
/**
* Returns the containing internal resource, or <code>null</code>.
*/
Resource.Internal eInternalResource();
/**
* Returns the directly containing internal resource, or
<code>null</code>.
*/
Resource.Internal eDirectResource();
As I understand it, there are basically two approaches to determine the
resource of an object:
1) walk up the containment relationship (eContainer) until that is null
(top level object) then return its resource (eDirectResource)
2) A non-top level object has for some reasons directly stored its
resource (eDirectResource), then return it (or null)
eResource() is just a public wrapper for the eInternalResource() which
does 1)
eDirectResource() does 2)
If that's correct, I'd say for most non-top level objects
eDirectResource() would return something (null) different from
eInternalResource() and eResource().
Ed, is that correct?
Can you please explain how these methods relate/differ to/from each other?
In any way a CDOObjectImpl should behave exactly according to the
sematics implied by EObject and InternalEObject. If that is not the
case, please file a Bugzilla.
Cheers
/Eike
Simon McDuff schrieb:
> I tried to complete my automatic persistence mechanism,
>
> I have one case I do not handle and it seems to be because one value in
> BasicEObject that is not set properly. In fact it is never set.
>
> eDirectResource is always null when we use CDO. Did we never want to set it
> ? (when we attach an object and/or when we load an object) ?
>
> Usually it is set when we attach an object to a resource...
>
> Simon
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03535 seconds
] 
Search
Help
Register
Login
Home
