|
Re: [CDO] CDO fails to generate ID for non-CDO EMF object [message #423614 is a reply to message #423607] |
Fri, 03 October 2008 07:10 |
|
Hi Stephen,
I have the feeling that you are using a 1.0.x version of CDO, right?
What you are describing sounds like what we call "external references" and
support for them has only been added to the 2.0 stream of CDO after
Ganymede:
213402: Support external references
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213402
Btw. this feature was neither proposed nor developed by me.
For respective questions I really hope that Simon's new computer
will work wonders soon again ;-)
Simon, at some convenient occasion I need to know how this feature
impacts the existing IStores (if at all) and what I need to do in the
DBStore!
Cheers
/Eike
Stephen McCants schrieb:
> Hello,
>
> I have a CDO-ized EMF model that has a non-containment, non-transient
> reference to an object in a different non-CDO EMF model. This works
> fine until I
> try to save the CDO model and then I get a IllegalStateException:
>
> java.lang.IllegalStateException: Unable to provideCDOID: <non-CDO EMF
> object>
> at
> org.eclipse.emf.internal.cdo.CDOViewImpl.provideCDOID(CDOVie wImpl.java:473)
>
> at
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl .writeValues(CDORevisionImpl.java:777)
>
> at
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl .write(CDORevisionImpl.java:160)
>
> at
> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.writeRevisions(CommitTransactionRequest.java:181)
>
> at
> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.requesting(CommitTransactionRequest.java:98)
>
> at
> org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:48)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at
> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:236)
>
> at org.eclipse.net4j.signal.SignalActor.send(SignalActor.java:5 0)
> at
> org.eclipse.net4j.signal.failover.NOOPFailOverStrategy.send( NOOPFailOverStrategy.java:34)
>
> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:239)
>
> at
> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>
> ....
>
> CDOViewImpl.provideCDOID(Object idOrObject) calls the function
> CDOViewImpl.convertObjectToID(Object potentialObject) that creates and
> returns a CDOAdapterImpl. Unfortunately, the provideCDOID(..)
> function doesn't do anything with the adapter returned to it and so it
> throws the IllegalStateException above.
>
> Is there something I should do to allow it to generate an ID for a
> normal EMF object
> stored outside the CDO model? Do we need to implement our own adapter
> somehow?
>
> Thanks in advanced!
>
> Sincerely,
> Stephen McCants
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
Re: [CDO] CDO fails to generate ID for non-CDO EMF object [message #423626 is a reply to message #423614] |
Fri, 03 October 2008 15:06 |
Stephen McCants Messages: 92 Registered: July 2009 |
Member |
|
|
Hello Eike,
Thank you for your quick reply. Yes, I am using 1.0 of CDO and I am talking about "external
references". For now, we are working without external references, but if we decide we really do
need them (and I expect we will), we'll move to 2.x.
Thanks again for your help!
Sincerely,
Stephen McCants
Eike Stepper wrote:
> Hi Stephen,
>
> I have the feeling that you are using a 1.0.x version of CDO, right?
> What you are describing sounds like what we call "external references" and
> support for them has only been added to the 2.0 stream of CDO after
> Ganymede:
>
> 213402: Support external references
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213402
>
> Btw. this feature was neither proposed nor developed by me.
> For respective questions I really hope that Simon's new computer
> will work wonders soon again ;-)
>
> Simon, at some convenient occasion I need to know how this feature
> impacts the existing IStores (if at all) and what I need to do in the
> DBStore!
>
> Cheers
> /Eike
>
>
> Stephen McCants schrieb:
>> Hello,
>>
>> I have a CDO-ized EMF model that has a non-containment, non-transient
>> reference to an object in a different non-CDO EMF model. This works
>> fine until I
>> try to save the CDO model and then I get a IllegalStateException:
>>
>> java.lang.IllegalStateException: Unable to provideCDOID: <non-CDO EMF
>> object>
>> at
>> org.eclipse.emf.internal.cdo.CDOViewImpl.provideCDOID(CDOVie wImpl.java:473)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl .writeValues(CDORevisionImpl.java:777)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl .write(CDORevisionImpl.java:160)
>>
>> at
>> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.writeRevisions(CommitTransactionRequest.java:181)
>>
>> at
>> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.requesting(CommitTransactionRequest.java:98)
>>
>> at
>> org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:48)
>>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
>> at
>> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:236)
>>
>> at org.eclipse.net4j.signal.SignalActor.send(SignalActor.java:5 0)
>> at
>> org.eclipse.net4j.signal.failover.NOOPFailOverStrategy.send( NOOPFailOverStrategy.java:34)
>>
>> at
>> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:239)
>>
>> at
>> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>>
>> ....
>>
>> CDOViewImpl.provideCDOID(Object idOrObject) calls the function
>> CDOViewImpl.convertObjectToID(Object potentialObject) that creates and
>> returns a CDOAdapterImpl. Unfortunately, the provideCDOID(..)
>> function doesn't do anything with the adapter returned to it and so it
>> throws the IllegalStateException above.
>>
>> Is there something I should do to allow it to generate an ID for a
>> normal EMF object
>> stored outside the CDO model? Do we need to implement our own adapter
>> somehow?
>>
>> Thanks in advanced!
>>
>> Sincerely,
>> Stephen McCants
|
|
|
|
Powered by
FUDForum. Page generated in 0.04278 seconds