Home » Modeling » EMF » SDO serialization and non-containment references
| SDO serialization and non-containment references [message #397547] |
Tue, 20 December 2005 07:53  |
Eclipse User |
|
|
|
Originally posted by: jerry-frain.austin.rr.com
Hi,
I have an SDO datagraph where a root object R contains objects A and B.
A and B have a bi-directional, non-containment relationship between them.
I'm not sure this if this sort of set up is just completely insane (from
the SDO perspective) or if there's some trick to get it to work.
In order to serialize this datagraph I have to put A and B into a
resource, or the serialization fails with a dangling href.
So, when the datagraph is serialized it tries to create proxy references
for A and B by asking the resource that they are now a member of.
While I can roll my own non-containment proxy resolving code, it strikes
me as quite odd that SDO doesn't just handle this, since all of the
objects are ultimately contained by the root.
Am I just missing something?
Thanks,
Jerry
|
|
|
| Re: SDO serialization and non-containment references [message #397552 is a reply to message #397547] |
Tue, 20 December 2005 10:21  |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Jerry,
If A and B are contained by R and R is the root of a resource, I don't
expect this to cause a problem. The library example has a
bi-directional reference between books and writers and that works fine.
But it sounds like A and B are not in the same resource or maybe not
even in a resource, and that simply won't work. SDO requires all the
objects references within the datagraph to be contained by that datagraph.
Jerry Frain wrote:
> Hi,
>
> I have an SDO datagraph where a root object R contains objects A and
> B. A and B have a bi-directional, non-containment relationship between
> them.
>
> I'm not sure this if this sort of set up is just completely insane
> (from the SDO perspective) or if there's some trick to get it to work.
>
> In order to serialize this datagraph I have to put A and B into a
> resource, or the serialization fails with a dangling href.
>
> So, when the datagraph is serialized it tries to create proxy
> references for A and B by asking the resource that they are now a
> member of.
>
> While I can roll my own non-containment proxy resolving code, it
> strikes me as quite odd that SDO doesn't just handle this, since all
> of the objects are ultimately contained by the root.
>
> Am I just missing something?
>
> Thanks,
>
> Jerry
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: SDO serialization and non-containment references [message #397557 is a reply to message #397552] |
Tue, 20 December 2005 15:07 |
| Eclipse User |
|
|
|
Originally posted by: jerry-frain.austin.rr.com
Ed Merks wrote:
> Jerry,
>
> If A and B are contained by R and R is the root of a resource, I don't
> expect this to cause a problem. The library example has a
> bi-directional reference between books and writers and that works fine.
> But it sounds like A and B are not in the same resource or maybe not
> even in a resource, and that simply won't work. SDO requires all the
> objects references within the datagraph to be contained by that datagraph.
Hi Ed,
Yeah, I get that they need to be in a resource to avoid dangling hrefs.
The question is which resource will make SDO happy?
I'm querying these object from a database. If I add them to the
datagraph root object's resource, I get IllegalArgumentExceptions
because "The feature 'eRootObject2' is not a valid feature." If I add
them to a new resource I create (e.g. an XMLResourceImpl), then SDO
serializes the reference to that resource.
I feel like I'm married to SDO, because I'm constantly asking myself
"What does it want?"
Thanks,
Jerry
|
|
|
| Re: SDO serialization and non-containment references [message #397558 is a reply to message #397557] |
Tue, 20 December 2005 15:24 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Jerry,
I can only hope that your significant other doesn't read the newsgroup! ;-)
There are few choices. The object must be contained directly or
indirectly by EDataGraph.getRootResource(), and since the data graph
must have a single root, the EDataGraph.getRootResource() must have a
single object. That leaves only the children of that resource as
potential parents for your object. You need something like the library
which contains the cross referencing books and writers.
Jerry Frain wrote:
> Ed Merks wrote:
>
>> Jerry,
>>
>> If A and B are contained by R and R is the root of a resource, I
>> don't expect this to cause a problem. The library example has a
>> bi-directional reference between books and writers and that works
>> fine. But it sounds like A and B are not in the same resource or
>> maybe not even in a resource, and that simply won't work. SDO
>> requires all the objects references within the datagraph to be
>> contained by that datagraph.
>
>
> Hi Ed,
>
> Yeah, I get that they need to be in a resource to avoid dangling
> hrefs. The question is which resource will make SDO happy?
>
> I'm querying these object from a database. If I add them to the
> datagraph root object's resource, I get IllegalArgumentExceptions
> because "The feature 'eRootObject2' is not a valid feature." If I add
> them to a new resource I create (e.g. an XMLResourceImpl), then SDO
> serializes the reference to that resource.
>
> I feel like I'm married to SDO, because I'm constantly asking myself
> "What does it want?"
>
> Thanks,
>
> Jerry
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: SDO serialization and non-containment references [message #397562 is a reply to message #397558] |
Tue, 20 December 2005 18:23 |
| Eclipse User |
|
|
|
Originally posted by: jerry-frain.austin.rr.com
Ed Merks wrote:
> Jerry,
>
> There are few choices. The object must be contained directly or
> indirectly by EDataGraph.getRootResource(), and since the data graph
> must have a single root, the EDataGraph.getRootResource() must have a
> single object. That leaves only the children of that resource as
> potential parents for your object. You need something like the library
> which contains the cross referencing books and writers.
Ok, I got it. The problem was that the containment references weren't
set up for my objects, and I didn't realize I'd have fix to up the
references manually. BTW, I'm using the elver hibernate implementation
to retrieve my objects, so I'm probably overlooking something important
there that would make this happen automagically.
Anyway my root object knew about it's children, but the children didn't
know that they were contained by the root. So I got dangling references
when attempting to serialize.
BTW, I had to tell the children about their container using
eBasicSetContainer(), because just calling the mutator setParent(parent)
caused parent to have duplicate entries for what should have been the
same child. I'm probably missing something simple, like a feature id
not being set either. I'll dig into it more later.
Thanks for your help, Ed.
Jerry
|
|
|
| Re: SDO serialization and non-containment references [message #397565 is a reply to message #397562] |
Tue, 20 December 2005 21:30 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Jerry,
This could be an Elver issue. When the parent and child are retrieved in
one session then this should normally work, or are you retrieving them
in different hb sessions?
The container of the children together with the container featureid are
stored in the database, so you can check there also.
This situation can also occur when hibernate proxies are used. In the
Elver svn version I have this enabled sometimes to test things out. A
symptom of this is that the parent has to a set of children but the
econtainer from the children points to a different instance of the same
parent, this last instance is then a cglib object.
gr. Martin
Jerry Frain wrote:
> Ed Merks wrote:
>
>> Jerry,
>>
>> There are few choices. The object must be contained directly or
>> indirectly by EDataGraph.getRootResource(), and since the data graph
>> must have a single root, the EDataGraph.getRootResource() must have a
>> single object. That leaves only the children of that resource as
>> potential parents for your object. You need something like the
>> library which contains the cross referencing books and writers.
>
>
> Ok, I got it. The problem was that the containment references weren't
> set up for my objects, and I didn't realize I'd have fix to up the
> references manually. BTW, I'm using the elver hibernate implementation
> to retrieve my objects, so I'm probably overlooking something important
> there that would make this happen automagically.
>
> Anyway my root object knew about it's children, but the children didn't
> know that they were contained by the root. So I got dangling references
> when attempting to serialize.
>
> BTW, I had to tell the children about their container using
> eBasicSetContainer(), because just calling the mutator setParent(parent)
> caused parent to have duplicate entries for what should have been the
> same child. I'm probably missing something simple, like a feature id
> not being set either. I'll dig into it more later.
>
> Thanks for your help, Ed.
>
> Jerry
|
|
| | |
Goto Forum:
Current Time: Tue Apr 16 13:17:56 GMT 2024
Powered by FUDForum. Page generated in 1.40834 seconds |
] 
Search
Help
Register
Login
Home
