Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] ExtendedLibrary sample with CDO ?
[CDO] ExtendedLibrary sample with CDO ? [message #422670] Fri, 12 September 2008 14:02 Go to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Hi,

Does anyone try to wire the Extended Library Editor (the one from EMF
examples) with CDO server ?

I'm not using the CDO session views.

I made some changes ExtendedLibrary editor to connect it to a CDO server,
open a session, get a transaction and create a cdo resource.

Problems raise when I try to add a new library with a writer.

All created objects seem to be transient. When debugging
CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this) always
answers true. Is it normal ?

When I commit the transaction, that fails with this message :
[ERROR] SQL Exception: The statement was aborted because it would have
caused a duplicate key value in a unique or primary key constraint or
unique index identified by 'CDORESOURCE_IDX0' defined on 'CDORESOURCE'.

Before I commit the transaction, I have no exception in eclipse log file.

N.B : Extended Library editor runs with an editing domain which is an EMF
Transactional one.

Does anyone have an idea ?

Stephane.
Re: [CDO] ExtendedLibrary sample with CDO ? [message #422674 is a reply to message #422670] Fri, 12 September 2008 14:59 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Stéphane Fournier schrieb:
> Hi,
>
> Does anyone try to wire the Extended Library Editor (the one from EMF
> examples) with CDO server ?
>
> I'm not using the CDO session views.
> I made some changes ExtendedLibrary editor to connect it to a CDO
> server, open a session, get a transaction and create a cdo resource.
>
> Problems raise when I try to add a new library with a writer.
>
> All created objects seem to be transient. When debugging
> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
> always answers true. Is it normal ?
I see you're using CDOObjectImpl but just to be sure: Did you regenerate
the Library model after migrating the genmodel to CDO?

Usually CDOObjects are TANSIENT as long as they're not attached to a
CDOTransaction. This is also true for CDOResource (which is a CDOObject,
too). How did you create the CDOResource?

The best way is transaction.createResource(path). If objects are then
attached to other objects that are already attached, the new objects
will also transition from TRANSIENT to NEW.

>
> When I commit the transaction, that fails with this message :
> [ERROR] SQL Exception: The statement was aborted because it would have
> caused a duplicate key value in a unique or primary key constraint or
> unique index identified by 'CDORESOURCE_IDX0' defined on 'CDORESOURCE'.
Looks as if a resource with that path (i.e. URI) is already stored in
the repository.
Either clear your database from previous attempts or use a different
resourcepath or call transaction.getOrCreateResource(path).

> Before I commit the transaction, I have no exception in eclipse log file.
>
> N.B : Extended Library editor runs with an editing domain which is an
> EMF Transactional one.
That's (IMHO) generally not a good idea!
Why do you add a second transactional layer on top of CDO?

Cheers
/Eike


Re: [CDO] ExtendedLibrary sample with CDO ? [message #422679 is a reply to message #422674] Fri, 12 September 2008 15:29 Go to previous messageGo to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Hi Eike,

Yes, I have generated the Extended Library model with changes in the
genmodel as mentionned in the "Preparing EMF Models for CDO" article.

To create a resource, I'm using transaction.createResource(path) method. I
have moved to getOrCreateResource() method.
Once, the resource is created, I add it to a resource set owned by a
transactional editing domain.

Now, at save time, I got this exception stack :
java.lang.IllegalStateException: Failing event COMMIT in state TRANSIENT
for CDOResource@oid1
(data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
at
org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
at
org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
at
org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
at
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
at
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)


My editor was already working with a transactional editing domain. I try
CDO to get a multi-user capability on my existing editor.
This editor is a GMF one that only works with a transational editing
domain.
My idea was to open a CDO transaction when the editor is opening. After
every save operation, I would like to commit the CDO transaction to really
flush data to the database.
Between save operations, my transactional editing domain listens to model
changes.

Stephane.

Eike Stepper wrote:

> Stéphane Fournier schrieb:
>> Hi,
>>
>> Does anyone try to wire the Extended Library Editor (the one from EMF
>> examples) with CDO server ?
>>
>> I'm not using the CDO session views.
>> I made some changes ExtendedLibrary editor to connect it to a CDO
>> server, open a session, get a transaction and create a cdo resource.
>>
>> Problems raise when I try to add a new library with a writer.
>>
>> All created objects seem to be transient. When debugging
>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>> always answers true. Is it normal ?
> I see you're using CDOObjectImpl but just to be sure: Did you regenerate
> the Library model after migrating the genmodel to CDO?

> Usually CDOObjects are TANSIENT as long as they're not attached to a
> CDOTransaction. This is also true for CDOResource (which is a CDOObject,
> too). How did you create the CDOResource?

> The best way is transaction.createResource(path). If objects are then
> attached to other objects that are already attached, the new objects
> will also transition from TRANSIENT to NEW.

>>
>> When I commit the transaction, that fails with this message :
>> [ERROR] SQL Exception: The statement was aborted because it would have
>> caused a duplicate key value in a unique or primary key constraint or
>> unique index identified by 'CDORESOURCE_IDX0' defined on 'CDORESOURCE'.
> Looks as if a resource with that path (i.e. URI) is already stored in
> the repository.
> Either clear your database from previous attempts or use a different
> resourcepath or call transaction.getOrCreateResource(path).

>> Before I commit the transaction, I have no exception in eclipse log file.
>>
>> N.B : Extended Library editor runs with an editing domain which is an
>> EMF Transactional one.
> That's (IMHO) generally not a good idea!
> Why do you add a second transactional layer on top of CDO?

> Cheers
> /Eike
Re: [CDO] ExtendedLibrary sample with CDO ? [message #422682 is a reply to message #422679] Fri, 12 September 2008 15:42 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Stéphane Fournier schrieb:
> Hi Eike,
>
> Yes, I have generated the Extended Library model with changes in the
> genmodel as mentionned in the "Preparing EMF Models for CDO" article.
>
> To create a resource, I'm using transaction.createResource(path)
> method. I have moved to getOrCreateResource() method. Once, the
> resource is created, I add it to a resource set owned by a
> transactional editing domain.
Ah! That's not allowed! Because ResourceSet.resources is like a
containment reference it's like a detach from the CDOTransaction!

The best thing you can do is not using EMF Transaction (sorry
Christian!) on top of CDO.

The second best thing you could try is:
1) Get the ResourceSet out of the TransactionalEditingDomain
2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead of
creating a new resource set


>
> Now, at save time, I got this exception stack :
> java.lang.IllegalStateException: Failing event COMMIT in state
> TRANSIENT for CDOResource@oid1
> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>
> at
> org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>
> at
> org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>
> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>
> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>
> at
> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>
>
>
> My editor was already working with a transactional editing domain. I
> try CDO to get a multi-user capability on my existing editor. This
> editor is a GMF one that only works with a transational editing domain.
> My idea was to open a CDO transaction when the editor is opening.
> After every save operation, I would like to commit the CDO transaction
> to really flush data to the database.
> Between save operations, my transactional editing domain listens to
> model changes.
Many users already asked for compatibility with GMF so I'm very
interested in your results. Please give feedback! ;-)

Cheers
/Eike


>

>
> Stephane.
>
> Eike Stepper wrote:
>
>> Stéphane Fournier schrieb:
>>> Hi,
>>>
>>> Does anyone try to wire the Extended Library Editor (the one from
>>> EMF examples) with CDO server ?
>>>
>>> I'm not using the CDO session views.
>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>> server, open a session, get a transaction and create a cdo resource.
>>>
>>> Problems raise when I try to add a new library with a writer.
>>>
>>> All created objects seem to be transient. When debugging
>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>> always answers true. Is it normal ?
>> I see you're using CDOObjectImpl but just to be sure: Did you
>> regenerate the Library model after migrating the genmodel to CDO?
>
>> Usually CDOObjects are TANSIENT as long as they're not attached to a
>> CDOTransaction. This is also true for CDOResource (which is a
>> CDOObject, too). How did you create the CDOResource?
>
>> The best way is transaction.createResource(path). If objects are then
>> attached to other objects that are already attached, the new objects
>> will also transition from TRANSIENT to NEW.
>
>>>
>>> When I commit the transaction, that fails with this message :
>>> [ERROR] SQL Exception: The statement was aborted because it would
>>> have caused a duplicate key value in a unique or primary key
>>> constraint or unique index identified by 'CDORESOURCE_IDX0' defined
>>> on 'CDORESOURCE'.
>> Looks as if a resource with that path (i.e. URI) is already stored in
>> the repository.
>> Either clear your database from previous attempts or use a different
>> resourcepath or call transaction.getOrCreateResource(path).
>
>>> Before I commit the transaction, I have no exception in eclipse log
>>> file.
>>>
>>> N.B : Extended Library editor runs with an editing domain which is
>>> an EMF Transactional one.
>> That's (IMHO) generally not a good idea!
>> Why do you add a second transactional layer on top of CDO?
>
>> Cheers
>> /Eike
>
>


Re: [CDO] ExtendedLibrary sample with CDO ? [message #422685 is a reply to message #422682] Fri, 12 September 2008 16:11 Go to previous messageGo to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Eike Stepper wrote:

I tried what you suggested at 2).
Now, I got the exception below. I'm using the embbeded derby store.

Indeed, after the resource creation a log mentionned that Legacy system is
not available. What does it mean ?

Ok, to give you feedbacks to run editor based on CDO and EMF Transaction,
if I succeed ;)

Stephane.

org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy system
not available
at
org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
at
org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
at
org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
at
org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
at
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
at
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
at
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
at
org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
at org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
at
org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
at
org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
at
org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
at
org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
at
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
at
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
at
com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)



> Stéphane Fournier schrieb:
>> Hi Eike,
>>
>> Yes, I have generated the Extended Library model with changes in the
>> genmodel as mentionned in the "Preparing EMF Models for CDO" article.
>>
>> To create a resource, I'm using transaction.createResource(path)
>> method. I have moved to getOrCreateResource() method. Once, the
>> resource is created, I add it to a resource set owned by a
>> transactional editing domain.
> Ah! That's not allowed! Because ResourceSet.resources is like a
> containment reference it's like a detach from the CDOTransaction!

> The best thing you can do is not using EMF Transaction (sorry
> Christian!) on top of CDO.

> The second best thing you could try is:
> 1) Get the ResourceSet out of the TransactionalEditingDomain
> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead of
> creating a new resource set


>>
>> Now, at save time, I got this exception stack :
>> java.lang.IllegalStateException: Failing event COMMIT in state
>> TRANSIENT for CDOResource@oid1
>> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>
>> at
>>
org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>>
>> at
>>
org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>>
>> at
>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>>
>> at
>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>>
>> at
>>
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>>
>>
>>
>> My editor was already working with a transactional editing domain. I
>> try CDO to get a multi-user capability on my existing editor. This
>> editor is a GMF one that only works with a transational editing domain.
>> My idea was to open a CDO transaction when the editor is opening.
>> After every save operation, I would like to commit the CDO transaction
>> to really flush data to the database.
>> Between save operations, my transactional editing domain listens to
>> model changes.
> Many users already asked for compatibility with GMF so I'm very
> interested in your results. Please give feedback! ;-)

> Cheers
> /Eike


>>

>>
>> Stephane.
>>
>> Eike Stepper wrote:
>>
>>> Stéphane Fournier schrieb:
>>>> Hi,
>>>>
>>>> Does anyone try to wire the Extended Library Editor (the one from
>>>> EMF examples) with CDO server ?
>>>>
>>>> I'm not using the CDO session views.
>>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>>> server, open a session, get a transaction and create a cdo resource.
>>>>
>>>> Problems raise when I try to add a new library with a writer.
>>>>
>>>> All created objects seem to be transient. When debugging
>>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>>> always answers true. Is it normal ?
>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>> regenerate the Library model after migrating the genmodel to CDO?
>>
>>> Usually CDOObjects are TANSIENT as long as they're not attached to a
>>> CDOTransaction. This is also true for CDOResource (which is a
>>> CDOObject, too). How did you create the CDOResource?
>>
>>> The best way is transaction.createResource(path). If objects are then
>>> attached to other objects that are already attached, the new objects
>>> will also transition from TRANSIENT to NEW.
>>
>>>>
>>>> When I commit the transaction, that fails with this message :
>>>> [ERROR] SQL Exception: The statement was aborted because it would
>>>> have caused a duplicate key value in a unique or primary key
>>>> constraint or unique index identified by 'CDORESOURCE_IDX0' defined
>>>> on 'CDORESOURCE'.
>>> Looks as if a resource with that path (i.e. URI) is already stored in
>>> the repository.
>>> Either clear your database from previous attempts or use a different
>>> resourcepath or call transaction.getOrCreateResource(path).
>>
>>>> Before I commit the transaction, I have no exception in eclipse log
>>>> file.
>>>>
>>>> N.B : Extended Library editor runs with an editing domain which is
>>>> an EMF Transactional one.
>>> That's (IMHO) generally not a good idea!
>>> Why do you add a second transactional layer on top of CDO?
>>
>>> Cheers
>>> /Eike
>>
>>
Re: [CDO] ExtendedLibrary sample with CDO ? [message #422687 is a reply to message #422685] Fri, 12 September 2008 16:55 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Stéphane Fournier schrieb:
> Eike Stepper wrote:
>
> I tried what you suggested at 2).
> Now, I got the exception below. I'm using the embbeded derby store.
>
> Indeed, after the resource creation a log mentionned that Legacy
> system is not available. What does it mean ?
Usually an indication that you are trying to attach non-native objects
to a transaction (or a bug).
but from the stack trace I can see that you're not using a brand new CDO
source from HEAD.
Only yesterday we committed substantial changes. Can youplease re-test
with newest HEAD?

Cheers
/Eike

>
> Ok, to give you feedbacks to run editor based on CDO and EMF
> Transaction, if I succeed ;)
>
> Stephane.
>
> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
> system not available
> at
> org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
>
> at
> org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
>
> at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
> at
> org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
>
> at
> org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
>
> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
>
> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
>
> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>
> at
> org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>
> at
> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
> at
> org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>
> at
> org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>
> at
> org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>
> at
> org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>
> at
> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>
> at
> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>
> at
> com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>
>
>
>
>> Stéphane Fournier schrieb:
>>> Hi Eike,
>>>
>>> Yes, I have generated the Extended Library model with changes in the
>>> genmodel as mentionned in the "Preparing EMF Models for CDO" article.
>>>
>>> To create a resource, I'm using transaction.createResource(path)
>>> method. I have moved to getOrCreateResource() method. Once, the
>>> resource is created, I add it to a resource set owned by a
>>> transactional editing domain.
>> Ah! That's not allowed! Because ResourceSet.resources is like a
>> containment reference it's like a detach from the CDOTransaction!
>
>> The best thing you can do is not using EMF Transaction (sorry
>> Christian!) on top of CDO.
>
>> The second best thing you could try is:
>> 1) Get the ResourceSet out of the TransactionalEditingDomain
>> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead
>> of creating a new resource set
>
>
>>>
>>> Now, at save time, I got this exception stack :
>>> java.lang.IllegalStateException: Failing event COMMIT in state
>>> TRANSIENT for CDOResource@oid1
>>> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>>
>>> at
> org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>
>>>
>>> at
> org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>
>>>
>>> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>
>>>
>>> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>
>>>
>>> at
> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>
>>>
>>>
>>>
>>> My editor was already working with a transactional editing domain. I
>>> try CDO to get a multi-user capability on my existing editor. This
>>> editor is a GMF one that only works with a transational editing domain.
>>> My idea was to open a CDO transaction when the editor is opening.
>>> After every save operation, I would like to commit the CDO
>>> transaction to really flush data to the database.
>>> Between save operations, my transactional editing domain listens to
>>> model changes.
>> Many users already asked for compatibility with GMF so I'm very
>> interested in your results. Please give feedback! ;-)
>
>> Cheers
>> /Eike
>
>
>>>
>
>>>
>>> Stephane.
>>>
>>> Eike Stepper wrote:
>>>
>>>> Stéphane Fournier schrieb:
>>>>> Hi,
>>>>>
>>>>> Does anyone try to wire the Extended Library Editor (the one from
>>>>> EMF examples) with CDO server ?
>>>>>
>>>>> I'm not using the CDO session views.
>>>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>>>> server, open a session, get a transaction and create a cdo resource.
>>>>>
>>>>> Problems raise when I try to add a new library with a writer.
>>>>>
>>>>> All created objects seem to be transient. When debugging
>>>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>>>> always answers true. Is it normal ?
>>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>>> regenerate the Library model after migrating the genmodel to CDO?
>>>
>>>> Usually CDOObjects are TANSIENT as long as they're not attached to
>>>> a CDOTransaction. This is also true for CDOResource (which is a
>>>> CDOObject, too). How did you create the CDOResource?
>>>
>>>> The best way is transaction.createResource(path). If objects are
>>>> then attached to other objects that are already attached, the new
>>>> objects will also transition from TRANSIENT to NEW.
>>>
>>>>>
>>>>> When I commit the transaction, that fails with this message :
>>>>> [ERROR] SQL Exception: The statement was aborted because it would
>>>>> have caused a duplicate key value in a unique or primary key
>>>>> constraint or unique index identified by 'CDORESOURCE_IDX0'
>>>>> defined on 'CDORESOURCE'.
>>>> Looks as if a resource with that path (i.e. URI) is already stored
>>>> in the repository.
>>>> Either clear your database from previous attempts or use a
>>>> different resourcepath or call transaction.getOrCreateResource(path).
>>>
>>>>> Before I commit the transaction, I have no exception in eclipse
>>>>> log file.
>>>>>
>>>>> N.B : Extended Library editor runs with an editing domain which is
>>>>> an EMF Transactional one.
>>>> That's (IMHO) generally not a good idea!
>>>> Why do you add a second transactional layer on top of CDO?
>>>
>>>> Cheers
>>>> /Eike
>>>
>>>
>
>


Re: [CDO] ExtendedLibrary sample with CDO ? [message #422696 is a reply to message #422687] Sat, 13 September 2008 19:53 Go to previous messageGo to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Ok Eike,
I'll check-out the latest release immediately.
I will test that on next Monday.

Stephane.

Eike Stepper wrote:

> Stéphane Fournier schrieb:
>> Eike Stepper wrote:
>>
>> I tried what you suggested at 2).
>> Now, I got the exception below. I'm using the embbeded derby store.
>>
>> Indeed, after the resource creation a log mentionned that Legacy
>> system is not available. What does it mean ?
> Usually an indication that you are trying to attach non-native objects
> to a transaction (or a bug).
> but from the stack trace I can see that you're not using a brand new CDO
> source from HEAD.
> Only yesterday we committed substantial changes. Can youplease re-test
> with newest HEAD?

> Cheers
> /Eike

>>
>> Ok, to give you feedbacks to run editor based on CDO and EMF
>> Transaction, if I succeed ;)
>>
>> Stephane.
>>
>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
>> system not available
>> at
>>
org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
>>
>> at
>>
org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
>>
>> at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
>> at
>>
org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
>>
>> at
>>
org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
>>
>> at
>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
>>
>> at
>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
>>
>> at
>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>>
>> at
>>
org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>>
>> at
>> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>> at
>>
org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>>
>> at
>>
org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>>
>> at
>>
org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>>
>> at
>>
org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>>
>> at
>>
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>>
>> at
>>
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>>
>> at
>>
com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>>
>>
>>
>>
>>> Stéphane Fournier schrieb:
>>>> Hi Eike,
>>>>
>>>> Yes, I have generated the Extended Library model with changes in the
>>>> genmodel as mentionned in the "Preparing EMF Models for CDO" article.
>>>>
>>>> To create a resource, I'm using transaction.createResource(path)
>>>> method. I have moved to getOrCreateResource() method. Once, the
>>>> resource is created, I add it to a resource set owned by a
>>>> transactional editing domain.
>>> Ah! That's not allowed! Because ResourceSet.resources is like a
>>> containment reference it's like a detach from the CDOTransaction!
>>
>>> The best thing you can do is not using EMF Transaction (sorry
>>> Christian!) on top of CDO.
>>
>>> The second best thing you could try is:
>>> 1) Get the ResourceSet out of the TransactionalEditingDomain
>>> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead
>>> of creating a new resource set
>>
>>
>>>>
>>>> Now, at save time, I got this exception stack :
>>>> java.lang.IllegalStateException: Failing event COMMIT in state
>>>> TRANSIENT for CDOResource@oid1
>>>>
(data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>>>
>>>> at
>>
org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>>
>>>>
>>>> at
>>
org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>>
>>>>
>>>> at
>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>>
>>>>
>>>> at
>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>>
>>>>
>>>> at
>>
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>>
>>>>
>>>>
>>>>
>>>> My editor was already working with a transactional editing domain. I
>>>> try CDO to get a multi-user capability on my existing editor. This
>>>> editor is a GMF one that only works with a transational editing domain.
>>>> My idea was to open a CDO transaction when the editor is opening.
>>>> After every save operation, I would like to commit the CDO
>>>> transaction to really flush data to the database.
>>>> Between save operations, my transactional editing domain listens to
>>>> model changes.
>>> Many users already asked for compatibility with GMF so I'm very
>>> interested in your results. Please give feedback! ;-)
>>
>>> Cheers
>>> /Eike
>>
>>
>>>>
>>
>>>>
>>>> Stephane.
>>>>
>>>> Eike Stepper wrote:
>>>>
>>>>> Stéphane Fournier schrieb:
>>>>>> Hi,
>>>>>>
>>>>>> Does anyone try to wire the Extended Library Editor (the one from
>>>>>> EMF examples) with CDO server ?
>>>>>>
>>>>>> I'm not using the CDO session views.
>>>>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>>>>> server, open a session, get a transaction and create a cdo resource.
>>>>>>
>>>>>> Problems raise when I try to add a new library with a writer.
>>>>>>
>>>>>> All created objects seem to be transient. When debugging
>>>>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>>>>> always answers true. Is it normal ?
>>>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>>>> regenerate the Library model after migrating the genmodel to CDO?
>>>>
>>>>> Usually CDOObjects are TANSIENT as long as they're not attached to
>>>>> a CDOTransaction. This is also true for CDOResource (which is a
>>>>> CDOObject, too). How did you create the CDOResource?
>>>>
>>>>> The best way is transaction.createResource(path). If objects are
>>>>> then attached to other objects that are already attached, the new
>>>>> objects will also transition from TRANSIENT to NEW.
>>>>
>>>>>>
>>>>>> When I commit the transaction, that fails with this message :
>>>>>> [ERROR] SQL Exception: The statement was aborted because it would
>>>>>> have caused a duplicate key value in a unique or primary key
>>>>>> constraint or unique index identified by 'CDORESOURCE_IDX0'
>>>>>> defined on 'CDORESOURCE'.
>>>>> Looks as if a resource with that path (i.e. URI) is already stored
>>>>> in the repository.
>>>>> Either clear your database from previous attempts or use a
>>>>> different resourcepath or call transaction.getOrCreateResource(path).
>>>>
>>>>>> Before I commit the transaction, I have no exception in eclipse
>>>>>> log file.
>>>>>>
>>>>>> N.B : Extended Library editor runs with an editing domain which is
>>>>>> an EMF Transactional one.
>>>>> That's (IMHO) generally not a good idea!
>>>>> Why do you add a second transactional layer on top of CDO?
>>>>
>>>>> Cheers
>>>>> /Eike
>>>>
>>>>
>>
>>
Re: [CDO] ExtendedLibrary sample with CDO ? [message #422697 is a reply to message #422696] Sat, 13 September 2008 21:08 Go to previous messageGo to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Comments below.
At home, I can use thunderbird to read newsgroup ouf :)
Stéphane Fournier wrote:
> Ok Eike, I'll check-out the latest release immediately.
> I will test that on next Monday.
>
> Stephane.
>

Hi Eike,
I checked out the latest release and I tested again. I got the exception
below.

When you said :
Usually an indication that you are trying to attach non-native objects
to a transaction (or a bug).

What does it mean exactly "attach non-native objects"? EMF objects that
do not extend CDO objects ?
I'm sorry if the question is stupid, but to make sure I've correctly
understand.

Stephane.


Exception stack :

org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
system not available
at
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl$Persisten tContents.inverseAdd(CDOResourceImpl.java:567)
at
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:448)
at
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
at
org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
at org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
at
org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
at
org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
at
org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
at
org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
at
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
at
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
at
com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
at
com.thalesgroup.mde.tig.ef.command.TigCommandStack.doExecute (TigCommandStack.java:40)
at
org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:164)
at
org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:217)
at
org.eclipse.emf.edit.ui.action.StaticSelectionCommandAction. run(StaticSelectionCommandAction.java:232)


> Eike Stepper wrote:
>
>> Stéphane Fournier schrieb:
>>> Eike Stepper wrote:
>>>
>>> I tried what you suggested at 2).
>>> Now, I got the exception below. I'm using the embbeded derby store.
>>>
>>> Indeed, after the resource creation a log mentionned that Legacy
>>> system is not available. What does it mean ?
>> Usually an indication that you are trying to attach non-native objects
>> to a transaction (or a bug).
>> but from the stack trace I can see that you're not using a brand new
>> CDO source from HEAD.
>> Only yesterday we committed substantial changes. Can youplease re-test
>> with newest HEAD?
>
>> Cheers
>> /Eike
>
>>>
>>> Ok, to give you feedbacks to run editor based on CDO and EMF
>>> Transaction, if I succeed ;)
>>>
>>> Stephane.
>>>
>>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
>>> system not available
>>> at
> org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
>
>>>
>>> at
> org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
>
>>>
>>> at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
>>> at
> org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
>
>>>
>>> at
> org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
>
>>>
>>> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
>
>>>
>>> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
>
>>>
>>> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>
>>>
>>> at
> org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>
>>>
>>> at
>>> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>>> at
> org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>
>>>
>>> at
> org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>
>>>
>>> at
> org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>
>>>
>>> at
> org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>
>>>
>>> at
> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>
>>>
>>> at
> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>
>>>
>>> at
> com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>
>>>
>>>
>>>
>>>
>>>> Stéphane Fournier schrieb:
>>>>> Hi Eike,
>>>>>
>>>>> Yes, I have generated the Extended Library model with changes in
>>>>> the genmodel as mentionned in the "Preparing EMF Models for CDO"
>>>>> article.
>>>>>
>>>>> To create a resource, I'm using transaction.createResource(path)
>>>>> method. I have moved to getOrCreateResource() method. Once, the
>>>>> resource is created, I add it to a resource set owned by a
>>>>> transactional editing domain.
>>>> Ah! That's not allowed! Because ResourceSet.resources is like a
>>>> containment reference it's like a detach from the CDOTransaction!
>>>
>>>> The best thing you can do is not using EMF Transaction (sorry
>>>> Christian!) on top of CDO.
>>>
>>>> The second best thing you could try is:
>>>> 1) Get the ResourceSet out of the TransactionalEditingDomain
>>>> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead
>>>> of creating a new resource set
>>>
>>>
>>>>>
>>>>> Now, at save time, I got this exception stack :
>>>>> java.lang.IllegalStateException: Failing event COMMIT in state
>>>>> TRANSIENT for CDOResource@oid1
> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>>>>
>>>>> at
>>>
> org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>
>>>
>>>>>
>>>>>
>>>>>
>>>>> My editor was already working with a transactional editing domain.
>>>>> I try CDO to get a multi-user capability on my existing editor.
>>>>> This editor is a GMF one that only works with a transational
>>>>> editing domain.
>>>>> My idea was to open a CDO transaction when the editor is opening.
>>>>> After every save operation, I would like to commit the CDO
>>>>> transaction to really flush data to the database.
>>>>> Between save operations, my transactional editing domain listens to
>>>>> model changes.
>>>> Many users already asked for compatibility with GMF so I'm very
>>>> interested in your results. Please give feedback! ;-)
>>>
>>>> Cheers
>>>> /Eike
>>>
>>>
>>>>>
>>>
>>>>>
>>>>> Stephane.
>>>>>
>>>>> Eike Stepper wrote:
>>>>>
>>>>>> Stéphane Fournier schrieb:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Does anyone try to wire the Extended Library Editor (the one from
>>>>>>> EMF examples) with CDO server ?
>>>>>>>
>>>>>>> I'm not using the CDO session views.
>>>>>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>>>>>> server, open a session, get a transaction and create a cdo resource.
>>>>>>>
>>>>>>> Problems raise when I try to add a new library with a writer.
>>>>>>>
>>>>>>> All created objects seem to be transient. When debugging
>>>>>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>>>>>> always answers true. Is it normal ?
>>>>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>>>>> regenerate the Library model after migrating the genmodel to CDO?
>>>>>
>>>>>> Usually CDOObjects are TANSIENT as long as they're not attached to
>>>>>> a CDOTransaction. This is also true for CDOResource (which is a
>>>>>> CDOObject, too). How did you create the CDOResource?
>>>>>
>>>>>> The best way is transaction.createResource(path). If objects are
>>>>>> then attached to other objects that are already attached, the new
>>>>>> objects will also transition from TRANSIENT to NEW.
>>>>>
>>>>>>>
>>>>>>> When I commit the transaction, that fails with this message :
>>>>>>> [ERROR] SQL Exception: The statement was aborted because it would
>>>>>>> have caused a duplicate key value in a unique or primary key
>>>>>>> constraint or unique index identified by 'CDORESOURCE_IDX0'
>>>>>>> defined on 'CDORESOURCE'.
>>>>>> Looks as if a resource with that path (i.e. URI) is already stored
>>>>>> in the repository.
>>>>>> Either clear your database from previous attempts or use a
>>>>>> different resourcepath or call transaction.getOrCreateResource(path).
>>>>>
>>>>>>> Before I commit the transaction, I have no exception in eclipse
>>>>>>> log file.
>>>>>>>
>>>>>>> N.B : Extended Library editor runs with an editing domain which
>>>>>>> is an EMF Transactional one.
>>>>>> That's (IMHO) generally not a good idea!
>>>>>> Why do you add a second transactional layer on top of CDO?
>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>
>>>>>
>>>
>>>
>
>
Re: [CDO] ExtendedLibrary sample with CDO ? [message #422699 is a reply to message #422697] Sun, 14 September 2008 00:47 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Hi Stephane,

CDO do not support Legacy object anymore.
I know Eike is currently working on a feature in EMF that will allow CDO to
support easily legacy objects. In my opinion, it is a question of time
(months. :-)).

To be able to persist objects through CDO please follow this guideline:
http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO#Modify_ an_Existing_GenModel

You just need to modify your genmodel.

Simon



"St
Re: [CDO] ExtendedLibrary sample with CDO ? [message #422720 is a reply to message #422699] Mon, 15 September 2008 08:46 Go to previous messageGo to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Thanks folks for your support !
I missed the following point : to create the marker file (CDO.MF).
I can test again mixing CDO transactions and EMFT transactions.

Stephane.


Simon McDuff wrote:

> Hi Stephane,

> CDO do not support Legacy object anymore.
> I know Eike is currently working on a feature in EMF that will allow CDO to
> support easily legacy objects. In my opinion, it is a question of time
> (months. :-)).

> To be able to persist objects through CDO please follow this guideline:
>
http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO#Modify_ an_Existing_GenModel

> You just need to modify your genmodel.

> Simon



> "Stéphane Fournier" <stephane.fournier@netcourrier.com> a écrit dans le
> message de news: gaha51$145$1@build.eclipse.org...
>> Comments below.
>> At home, I can use thunderbird to read newsgroup ouf :)
>> Stéphane Fournier wrote:
>>> Ok Eike, I'll check-out the latest release immediately.
>>> I will test that on next Monday.
>>>
>>> Stephane.
>>>
>>
>> Hi Eike,
>> I checked out the latest release and I tested again. I got the exception
>> below.
>>
>> When you said :
>> Usually an indication that you are trying to attach non-native objects to
>> a transaction (or a bug).
>>
>> What does it mean exactly "attach non-native objects"? EMF objects that do
>> not extend CDO objects ?
>> I'm sorry if the question is stupid, but to make sure I've correctly
>> understand.
>>
>> Stephane.
>>
>>
>> Exception stack :
>>
>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy system
>> not available
>> at
>>
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl$Persisten tContents.inverseAdd(CDOResourceImpl.java:567)
>> at
>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:448)
>> at
>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>> at
>> org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>> at org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>> at
>>
org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>> at
>>
org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>> at
>>
org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>> at
>>
org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>> at
>>
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>> at
>>
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>> at
>>
com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>> at
>>
com.thalesgroup.mde.tig.ef.command.TigCommandStack.doExecute (TigCommandStack.java:40)
>> at
>>
org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:164)
>> at
>>
org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:217)
>> at
>>
org.eclipse.emf.edit.ui.action.StaticSelectionCommandAction. run(StaticSelectionCommandAction.java:232)
>>
>>
>>> Eike Stepper wrote:
>>>
>>>> Stéphane Fournier schrieb:
>>>>> Eike Stepper wrote:
>>>>>
>>>>> I tried what you suggested at 2).
>>>>> Now, I got the exception below. I'm using the embbeded derby store.
>>>>>
>>>>> Indeed, after the resource creation a log mentionned that Legacy system
>>>>> is not available. What does it mean ?
>>>> Usually an indication that you are trying to attach non-native objects
>>>> to a transaction (or a bug).
>>>> but from the stack trace I can see that you're not using a brand new CDO
>>>> source from HEAD.
>>>> Only yesterday we committed substantial changes. Can youplease re-test
>>>> with newest HEAD?
>>>
>>>> Cheers
>>>> /Eike
>>>
>>>>>
>>>>> Ok, to give you feedbacks to run editor based on CDO and EMF
>>>>> Transaction, if I succeed ;)
>>>>>
>>>>> Stephane.
>>>>>
>>>>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
>>>>> system not available
>>>>> at
>>>
org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
>>>>>
>>>>> at
>>>
org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
>>>>>
>>>>> at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
>>>>> at
>>>
org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>>>>> at
>>>
org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>>>>>
>>>>> at
>>>
org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>>>>>
>>>>> at
>>>
org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>>>>>
>>>>> at
>>>
org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>>>>>
>>>>> at
>>>
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>>>>>
>>>>> at
>>>
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>>>>>
>>>>> at
>>>
com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Stéphane Fournier schrieb:
>>>>>>> Hi Eike,
>>>>>>>
>>>>>>> Yes, I have generated the Extended Library model with changes in the
>>>>>>> genmodel as mentionned in the "Preparing EMF Models for CDO" article.
>>>>>>>
>>>>>>> To create a resource, I'm using transaction.createResource(path)
>>>>>>> method. I have moved to getOrCreateResource() method. Once, the
>>>>>>> resource is created, I add it to a resource set owned by a
>>>>>>> transactional editing domain.
>>>>>> Ah! That's not allowed! Because ResourceSet.resources is like a
>>>>>> containment reference it's like a detach from the CDOTransaction!
>>>>>
>>>>>> The best thing you can do is not using EMF Transaction (sorry
>>>>>> Christian!) on top of CDO.
>>>>>
>>>>>> The second best thing you could try is:
>>>>>> 1) Get the ResourceSet out of the TransactionalEditingDomain
>>>>>> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1) instead of
>>>>>> creating a new resource set
>>>>>
>>>>>
>>>>>>>
>>>>>>> Now, at save time, I got this exception stack :
>>>>>>> java.lang.IllegalStateException: Failing event COMMIT in state
>>>>>>> TRANSIENT for CDOResource@oid1
>>> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>>>>>>
>>>>>>> at
>>>>>
>>>
org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>
>>>
org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>
>>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>
>>>
org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>>>>>
>>>>>>>
>>>>>>> at
>>>>>
>>>
org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My editor was already working with a transactional editing domain. I
>>>>>>> try CDO to get a multi-user capability on my existing editor. This
>>>>>>> editor is a GMF one that only works with a transational editing
>>>>>>> domain.
>>>>>>> My idea was to open a CDO transaction when the editor is opening.
>>>>>>> After every save operation, I would like to commit the CDO
>>>>>>> transaction to really flush data to the database.
>>>>>>> Between save operations, my transactional editing domain listens to
>>>>>>> model changes.
>>>>>> Many users already asked for compatibility with GMF so I'm very
>>>>>> interested in your results. Please give feedback! ;-)
>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>
>>>>>
>>>>>>>
>>>>>
>>>>>>>
>>>>>>> Stephane.
>>>>>>>
>>>>>>> Eike Stepper wrote:
>>>>>>>
>>>>>>>> Stéphane Fournier schrieb:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Does anyone try to wire the Extended Library Editor (the one from
>>>>>>>>> EMF examples) with CDO server ?
>>>>>>>>>
>>>>>>>>> I'm not using the CDO session views.
>>>>>>>>> I made some changes ExtendedLibrary editor to connect it to a CDO
>>>>>>>>> server, open a session, get a transaction and create a cdo
>>>>>>>>> resource.
>>>>>>>>>
>>>>>>>>> Problems raise when I try to add a new library with a writer.
>>>>>>>>>
>>>>>>>>> All created objects seem to be transient. When debugging
>>>>>>>>> CDOObjectImpl.dynamicSet() method, and FSMUtil.isTransient(this)
>>>>>>>>> always answers true. Is it normal ?
>>>>>>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>>>>>>> regenerate the Library model after migrating the genmodel to CDO?
>>>>>>>
>>>>>>>> Usually CDOObjects are TANSIENT as long as they're not attached to a
>>>>>>>> CDOTransaction. This is also true for CDOResource (which is a
>>>>>>>> CDOObject, too). How did you create the CDOResource?
>>>>>>>
>>>>>>>> The best way is transaction.createResource(path). If objects are
>>>>>>>> then attached to other objects that are already attached, the new
>>>>>>>> objects will also transition from TRANSIENT to NEW.
>>>>>>>
>>>>>>>>>
>>>>>>>>> When I commit the transaction, that fails with this message :
>>>>>>>>> [ERROR] SQL Exception: The statement was aborted because it would
>>>>>>>>> have caused a duplicate key value in a unique or primary key
>>>>>>>>> constraint or unique index identified by 'CDORESOURCE_IDX0' defined
>>>>>>>>> on 'CDORESOURCE'.
>>>>>>>> Looks as if a resource with that path (i.e. URI) is already stored
>>>>>>>> in the repository.
>>>>>>>> Either clear your database from previous attempts or use a different
>>>>>>>> resourcepath or call transaction.getOrCreateResource(path).
>>>>>>>
>>>>>>>>> Before I commit the transaction, I have no exception in eclipse log
>>>>>>>>> file.
>>>>>>>>>
>>>>>>>>> N.B : Extended Library editor runs with an editing domain which is
>>>>>>>>> an EMF Transactional one.
>>>>>>>> That's (IMHO) generally not a good idea!
>>>>>>>> Why do you add a second transactional layer on top of CDO?
>>>>>>>
>>>>>>>> Cheers
>>>>>>>> /Eike
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
Re: [CDO] ExtendedLibrary sample with CDO ? [message #422721 is a reply to message #422720] Mon, 15 September 2008 09:27 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Stéphane Fournier schrieb:
> Thanks folks for your support !
> I missed the following point : to create the marker file (CDO.MF).
Gosh! People always used to criticize me for the lack of documentation
and now you don't read it! :P

> I can test again mixing CDO transactions and EMFT transactions.
>
> Stephane.
>
>
> Simon McDuff wrote:
>
>> Hi Stephane,
>
>> CDO do not support Legacy object anymore.
>> I know Eike is currently working on a feature in EMF that will allow
>> CDO to support easily legacy objects. In my opinion, it is a question
>> of time (months. :-)).
>
>> To be able to persist objects through CDO please follow this guideline:
>>
> http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO#Modify_ an_Existing_GenModel
>
>
>> You just need to modify your genmodel.
>
>> Simon
>
>
>
>> "Stéphane Fournier" <stephane.fournier@netcourrier.com> a écrit dans
>> le message de news: gaha51$145$1@build.eclipse.org...
>>> Comments below.
>>> At home, I can use thunderbird to read newsgroup ouf :)
>>> Stéphane Fournier wrote:
>>>> Ok Eike, I'll check-out the latest release immediately.
>>>> I will test that on next Monday.
>>>>
>>>> Stephane.
>>>>
>>>
>>> Hi Eike,
>>> I checked out the latest release and I tested again. I got the
>>> exception below.
>>>
>>> When you said :
>>> Usually an indication that you are trying to attach non-native
>>> objects to a transaction (or a bug).
>>>
>>> What does it mean exactly "attach non-native objects"? EMF objects
>>> that do not extend CDO objects ?
>>> I'm sorry if the question is stupid, but to make sure I've correctly
>>> understand.
>>>
>>> Stephane.
>>>
>>>
>>> Exception stack :
>>>
>>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException: Legacy
>>> system not available
>>> at
> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl$Persisten tContents.inverseAdd(CDOResourceImpl.java:567)
>
>>> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:448)
>
>>> at
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>
>>> at
>>> org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>>>
>>> at
>>> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>>> at
> org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>
>>> at
> org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>
>>> at
> org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>
>>> at
> org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>
>>> at
> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>
>>> at
> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>
>>> at
> com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>
>>> at
> com.thalesgroup.mde.tig.ef.command.TigCommandStack.doExecute (TigCommandStack.java:40)
>
>>> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:164)
>
>>> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:217)
>
>>> at
> org.eclipse.emf.edit.ui.action.StaticSelectionCommandAction. run(StaticSelectionCommandAction.java:232)
>
>>>
>>>
>>>> Eike Stepper wrote:
>>>>
>>>>> Stéphane Fournier schrieb:
>>>>>> Eike Stepper wrote:
>>>>>>
>>>>>> I tried what you suggested at 2).
>>>>>> Now, I got the exception below. I'm using the embbeded derby store.
>>>>>>
>>>>>> Indeed, after the resource creation a log mentionned that Legacy
>>>>>> system is not available. What does it mean ?
>>>>> Usually an indication that you are trying to attach non-native
>>>>> objects to a transaction (or a bug).
>>>>> but from the stack trace I can see that you're not using a brand
>>>>> new CDO source from HEAD.
>>>>> Only yesterday we committed substantial changes. Can youplease
>>>>> re-test with newest HEAD?
>>>>
>>>>> Cheers
>>>>> /Eike
>>>>
>>>>>>
>>>>>> Ok, to give you feedbacks to run editor based on CDO and EMF
>>>>>> Transaction, if I succeed ;)
>>>>>>
>>>>>> Stephane.
>>>>>>
>>>>>> org.eclipse.emf.cdo.util.LegacySystemNotAvailableException:
>>>>>> Legacy system not available
>>>>>> at
>>>>
> org.eclipse.emf.internal.cdo.util.FSMUtil.checkLegacySystemA vailability(FSMUtil.java:82)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.internal.cdo.CDOStore.handleContainmentAdd(C DOStore.java:562)
>
>>>>>>
>>>>>> at org.eclipse.emf.internal.cdo.CDOStore.add(CDOStore.java:427)
>>>>>> at
>>>>
> org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateAdd(CDOObjectImpl.java:666)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.util.DelegatingEList.addAllUnique(Del egatingEList.java:671)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.doAddAllUnique(DelegatingNotifyingListImpl.java:495)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:436)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.notify.impl.DelegatingNotifyingListIm pl.addAllUnique(DelegatingNotifyingListImpl.java:396)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.util.DelegatingEList.addAll(Delegatin gEList.java:593)
>
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.edit.command.AddCommand.doExecute(AddCommand .java:403)
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.edit.command.AbstractOverrideableCommand.exe cute(AbstractOverrideableCommand.java:129)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.common.command.CommandWrapper.execute(Comman dWrapper.java:180)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.edit.command.CreateChildCommand.execute(Crea teChildCommand.java:263)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFC ommandOperation.java:116)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:137)
>
>>>>>>
>>>>>> at
>>>>
> org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:511)
>
>>>>>>
>>>>>> at
>>>>
> com.thalesgroup.mde.tig.ef.internal.command.WorkspaceCommand StackImpl.doExecute(WorkspaceCommandStackImpl.java:125)
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Stéphane Fournier schrieb:
>>>>>>>> Hi Eike,
>>>>>>>>
>>>>>>>> Yes, I have generated the Extended Library model with changes
>>>>>>>> in the genmodel as mentionned in the "Preparing EMF Models for
>>>>>>>> CDO" article.
>>>>>>>>
>>>>>>>> To create a resource, I'm using
>>>>>>>> transaction.createResource(path) method. I have moved to
>>>>>>>> getOrCreateResource() method. Once, the resource is created, I
>>>>>>>> add it to a resource set owned by a transactional editing domain.
>>>>>>> Ah! That's not allowed! Because ResourceSet.resources is like a
>>>>>>> containment reference it's like a detach from the CDOTransaction!
>>>>>>
>>>>>>> The best thing you can do is not using EMF Transaction (sorry
>>>>>>> Christian!) on top of CDO.
>>>>>>
>>>>>>> The second best thing you could try is:
>>>>>>> 1) Get the ResourceSet out of the TransactionalEditingDomain
>>>>>>> 2) Call CDOSession.openTransaction(resourceSet) to reuse 1)
>>>>>>> instead of creating a new resource set
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Now, at save time, I got this exception stack :
>>>>>>>> java.lang.IllegalStateException: Failing event COMMIT in state
>>>>>>>> TRANSIENT for CDOResource@oid1
>>>> (data= org.eclipse.emf.internal.cdo.protocol.CommitTransactionResul t @d8d767)
>>>>
>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>
> org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:152)
>
>>>>>>
>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>
> org.eclipse.emf.internal.cdo.CDOStateMachine.commit(CDOState Machine.java:274)
>
>>>>>>
>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.postCommit(C DOTransactionImpl.java:475)
>
>>>>>>
>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:246)
>
>>>>>>
>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>
> org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOR esourceImpl.java:369)
>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> My editor was already working with a transactional editing
>>>>>>>> domain. I try CDO to get a multi-user capability on my existing
>>>>>>>> editor. This editor is a GMF one that only works with a
>>>>>>>> transational editing domain.
>>>>>>>> My idea was to open a CDO transaction when the editor is
>>>>>>>> opening. After every save operation, I would like to commit the
>>>>>>>> CDO transaction to really flush data to the database.
>>>>>>>> Between save operations, my transactional editing domain
>>>>>>>> listens to model changes.
>>>>>>> Many users already asked for compatibility with GMF so I'm very
>>>>>>> interested in your results. Please give feedback! ;-)
>>>>>>
>>>>>>> Cheers
>>>>>>> /Eike
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Stephane.
>>>>>>>>
>>>>>>>> Eike Stepper wrote:
>>>>>>>>
>>>>>>>>> Stéphane Fournier schrieb:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Does anyone try to wire the Extended Library Editor (the one
>>>>>>>>>> from EMF examples) with CDO server ?
>>>>>>>>>>
>>>>>>>>>> I'm not using the CDO session views.
>>>>>>>>>> I made some changes ExtendedLibrary editor to connect it to a
>>>>>>>>>> CDO server, open a session, get a transaction and create a
>>>>>>>>>> cdo resource.
>>>>>>>>>>
>>>>>>>>>> Problems raise when I try to add a new library with a writer.
>>>>>>>>>>
>>>>>>>>>> All created objects seem to be transient. When debugging
>>>>>>>>>> CDOObjectImpl.dynamicSet() method, and
>>>>>>>>>> FSMUtil.isTransient(this) always answers true. Is it normal ?
>>>>>>>>> I see you're using CDOObjectImpl but just to be sure: Did you
>>>>>>>>> regenerate the Library model after migrating the genmodel to CDO?
>>>>>>>>
>>>>>>>>> Usually CDOObjects are TANSIENT as long as they're not
>>>>>>>>> attached to a CDOTransaction. This is also true for
>>>>>>>>> CDOResource (which is a CDOObject, too). How did you create
>>>>>>>>> the CDOResource?
>>>>>>>>
>>>>>>>>> The best way is transaction.createResource(path). If objects
>>>>>>>>> are then attached to other objects that are already attached,
>>>>>>>>> the new objects will also transition from TRANSIENT to NEW.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When I commit the transaction, that fails with this message :
>>>>>>>>>> [ERROR] SQL Exception: The statement was aborted because it
>>>>>>>>>> would have caused a duplicate key value in a unique or
>>>>>>>>>> primary key constraint or unique index identified by
>>>>>>>>>> 'CDORESOURCE_IDX0' defined on 'CDORESOURCE'.
>>>>>>>>> Looks as if a resource with that path (i.e. URI) is already
>>>>>>>>> stored in the repository.
>>>>>>>>> Either clear your database from previous attempts or use a
>>>>>>>>> different resourcepath or call
>>>>>>>>> transaction.getOrCreateResource(path).
>>>>>>>>
>>>>>>>>>> Before I commit the transaction, I have no exception in
>>>>>>>>>> eclipse log file.
>>>>>>>>>>
>>>>>>>>>> N.B : Extended Library editor runs with an editing domain
>>>>>>>>>> which is an EMF Transactional one.
>>>>>>>>> That's (IMHO) generally not a good idea!
>>>>>>>>> Why do you add a second transactional layer on top of CDO?
>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> /Eike
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>
>


Previous Topic:Problems when referencing ChangeDescription
Next Topic:[Teneo] Different generation using opposite
Goto Forum:
  


Current Time: Wed Jan 22 04:43:57 GMT 2020

Powered by FUDForum. Page generated in 0.02506 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top