Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » [Teneo] : VersionPropertyHandler returns null for dettached objects

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Teneo] : VersionPropertyHandler returns null for dettached objects

Show: Today's Messages :: Show Polls :: Message Navigator

[Teneo] : VersionPropertyHandler returns null for dettached objects [message #86580]

Sat, 16 June 2007 15:57

Duncan Alexander

Messages: 90
Registered: July 2009

Member

Hi,

I think the VersionPropertyHandler
(org.eclipse.emf.teneo.hibernate.mapping.property.VersionPro pertyHandler) may be causing me problems
in that it is returning null values when I attempt to reattach a dettached object.

If I create a new version of an object and assign it the same ID as one persisted in the DB, then
this should act in the same way as an object which has been retireved from persistent storage in
another session. But if I do this through Teneo it throws an error like:

java.lang.NullPointerException
at org.hibernate.type.IntegerType.next(IntegerType.java:59)
at org.hibernate.engine.Versioning.increment(Versioning.java:10 8)
at
org.hibernate.event.def.DefaultFlushEntityEventListener.getN extVersion(DefaultFlushEntityEventListener.java:358)
at
org.hibernate.event.def.DefaultFlushEntityEventListener.sche duleUpdate(DefaultFlushEntityEventListener.java:250)
at
org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:121)
at
org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
at
org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at
system.org.sdmx.registry.persistence.HibernateTestHarness.te stCreatingNewVersionOfExistingCategoryAndUpdating(HibernateT estHarness.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStar ter.java:32)

I can see from debugging the Teneo classes that the VersionPropertyHandler class is attempting to
look up version numbers for the dettached objects and is returning null. It does however
successfully return 0 as the version for new objects.

Is the VersionPropertyHandler acting correctly in assuming that there should always be a version
number in its IdentifierCacheHandler for dettached objects ? It seems that it should be checking for
versions in the DB if it finds that an object already exists.

regards

Duncan

Report message to a moderator

Re: [Teneo] : VersionPropertyHandler returns null for dettached objects [message #86596 is a reply to message #86580]

Sat, 16 June 2007 17:57

Duncan Alexander

Messages: 90
Registered: July 2009

Member

...Bit of further info....

discovered that if I manually assign a version number for my new objects by calling

IdentifierCacheHandler.setVersion(<<myobject>>, Integer.valueOf(<<version no>>));

....and as long as the version number matches what is in the DB then the update will work fine.

Not sure if there is a bug or if I am misunderstanding the use of the version column for optimistic
concurrency.

Duncan

Duncan ALexander wrote:
> Hi,
>
> I think the VersionPropertyHandler
> (org.eclipse.emf.teneo.hibernate.mapping.property.VersionPro pertyHandler)
> may be causing me problems in that it is returning null values when I
> attempt to reattach a dettached object.
>
> If I create a new version of an object and assign it the same ID as one
> persisted in the DB, then this should act in the same way as an object
> which has been retireved from persistent storage in another session. But
> if I do this through Teneo it throws an error like:
>
> java.lang.NullPointerException
> at org.hibernate.type.IntegerType.next(IntegerType.java:59)
> at org.hibernate.engine.Versioning.increment(Versioning.java:10 8)
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.getN extVersion(DefaultFlushEntityEventListener.java:358)
>
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.sche duleUpdate(DefaultFlushEntityEventListener.java:250)
>
> at
> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:121)
>
> at
> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>
> at
> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>
> at
> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
> at
> system.org.sdmx.registry.persistence.HibernateTestHarness.te stCreatingNewVersionOfExistingCategoryAndUpdating(HibernateT estHarness.java:90)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>
> at
> com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStar ter.java:32)
>
> I can see from debugging the Teneo classes that the
> VersionPropertyHandler class is attempting to look up version numbers
> for the dettached objects and is returning null. It does however
> successfully return 0 as the version for new objects.
>
> Is the VersionPropertyHandler acting correctly in assuming that there
> should always be a version number in its IdentifierCacheHandler for
> dettached objects ? It seems that it should be checking for versions in
> the DB if it finds that an object already exists.
>
> regards
>
> Duncan

Report message to a moderator

Re: [Teneo] : VersionPropertyHandler returns null for dettached objects [message #86611 is a reply to message #86596]

Sat, 16 June 2007 21:03

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Duncan,
Yes this can be the cause. See here:
http://www.elver.org/hibernate/hibernate_details.html#Synthe tic+ID+and+Version+properties

It is not a bug but just the way the version column works (in hibernate). It is easiest to have an
explicit version efeature in your model (annotated with @Version).
Another solution is the approach you chose, read the version from the db and set it in the
identifiercachehandler.
Or you can try the session.merge command, I have not tried this, but it works differently than update.

gr. Martin

Duncan ALexander wrote:
> ...Bit of further info....
>
> discovered that if I manually assign a version number for my new objects
> by calling
>
> IdentifierCacheHandler.setVersion(<<myobject>>,
> Integer.valueOf(<<version no>>));
>
> ....and as long as the version number matches what is in the DB then the
> update will work fine.
>
> Not sure if there is a bug or if I am misunderstanding the use of the
> version column for optimistic concurrency.
>
> Duncan
>
> Duncan ALexander wrote:
>> Hi,
>>
>> I think the VersionPropertyHandler
>> (org.eclipse.emf.teneo.hibernate.mapping.property.VersionPro pertyHandler)
>> may be causing me problems in that it is returning null values when I
>> attempt to reattach a dettached object.
>>
>> If I create a new version of an object and assign it the same ID as
>> one persisted in the DB, then this should act in the same way as an
>> object which has been retireved from persistent storage in another
>> session. But if I do this through Teneo it throws an error like:
>>
>> java.lang.NullPointerException
>> at org.hibernate.type.IntegerType.next(IntegerType.java:59)
>> at org.hibernate.engine.Versioning.increment(Versioning.java:10 8)
>> at
>> org.hibernate.event.def.DefaultFlushEntityEventListener.getN extVersion(DefaultFlushEntityEventListener.java:358)
>>
>> at
>> org.hibernate.event.def.DefaultFlushEntityEventListener.sche duleUpdate(DefaultFlushEntityEventListener.java:250)
>>
>> at
>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:121)
>>
>> at
>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>
>> at
>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>
>> at
>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>
>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>> at
>> system.org.sdmx.registry.persistence.HibernateTestHarness.te stCreatingNewVersionOfExistingCategoryAndUpdating(HibernateT estHarness.java:90)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>
>> at
>> com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStar ter.java:32)
>>
>> I can see from debugging the Teneo classes that the
>> VersionPropertyHandler class is attempting to look up version numbers
>> for the dettached objects and is returning null. It does however
>> successfully return 0 as the version for new objects.
>>
>> Is the VersionPropertyHandler acting correctly in assuming that there
>> should always be a version number in its IdentifierCacheHandler for
>> dettached objects ? It seems that it should be checking for versions
>> in the DB if it finds that an object already exists.
>>
>> regards
>>
>> Duncan

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: [Teneo] : VersionPropertyHandler returns null for dettached objects [message #86653 is a reply to message #86611]

Mon, 18 June 2007 09:32

Duncan Alexander

Messages: 90
Registered: July 2009

Member

Ok,
it makes perfect sense now that I think about it a bit more. Why do these things seem so simple
after the "...penny has dropped..." ?

I think my problem is that I dont want a version column at all as my application is rather unusual
in that anything that is submitted to the DB should always overwrite what is already there.

I have now switched off the synthetic version column by setting the Teneo persistence option.
persistenceProperties.setProperty(PersistenceOptions.ALWAYS_ VERSION, "false");

This has moved me forward now so thanks again.

Duncan

Martin Taal wrote:
> Hi Duncan,
> Yes this can be the cause. See here:
> http://www.elver.org/hibernate/hibernate_details.html#Synthe tic+ID+and+Version+properties
>
>
> It is not a bug but just the way the version column works (in
> hibernate). It is easiest to have an explicit version efeature in your
> model (annotated with @Version).
> Another solution is the approach you chose, read the version from the db
> and set it in the identifiercachehandler.
> Or you can try the session.merge command, I have not tried this, but it
> works differently than update.
>
> gr. Martin
>
> Duncan ALexander wrote:
>> ...Bit of further info....
>>
>> discovered that if I manually assign a version number for my new
>> objects by calling
>>
>> IdentifierCacheHandler.setVersion(<<myobject>>,
>> Integer.valueOf(<<version no>>));
>>
>> ....and as long as the version number matches what is in the DB then
>> the update will work fine.
>>
>> Not sure if there is a bug or if I am misunderstanding the use of the
>> version column for optimistic concurrency.
>>
>> Duncan
>>
>> Duncan ALexander wrote:
>>> Hi,
>>>
>>> I think the VersionPropertyHandler
>>> (org.eclipse.emf.teneo.hibernate.mapping.property.VersionPro pertyHandler)
>>> may be causing me problems in that it is returning null values when
>>> I attempt to reattach a dettached object.
>>>
>>> If I create a new version of an object and assign it the same ID as
>>> one persisted in the DB, then this should act in the same way as an
>>> object which has been retireved from persistent storage in another
>>> session. But if I do this through Teneo it throws an error like:
>>>
>>> java.lang.NullPointerException
>>> at org.hibernate.type.IntegerType.next(IntegerType.java:59)
>>> at org.hibernate.engine.Versioning.increment(Versioning.java:10 8)
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getN extVersion(DefaultFlushEntityEventListener.java:358)
>>>
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.sche duleUpdate(DefaultFlushEntityEventListener.java:250)
>>>
>>> at
>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFl ushEntity(DefaultFlushEntityEventListener.java:121)
>>>
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE ntities(AbstractFlushingEventListener.java:196)
>>>
>>> at
>>> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:76)
>>>
>>> at
>>> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>>>
>>> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
>>> at
>>> system.org.sdmx.registry.persistence.HibernateTestHarness.te stCreatingNewVersionOfExistingCategoryAndUpdating(HibernateT estHarness.java:90)
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>>
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>>
>>> at
>>> com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStar ter.java:32)
>>>
>>> I can see from debugging the Teneo classes that the
>>> VersionPropertyHandler class is attempting to look up version numbers
>>> for the dettached objects and is returning null. It does however
>>> successfully return 0 as the version for new objects.
>>>
>>> Is the VersionPropertyHandler acting correctly in assuming that there
>>> should always be a version number in its IdentifierCacheHandler for
>>> dettached objects ? It seems that it should be checking for versions
>>> in the DB if it finds that an object already exists.
>>>
>>> regards
>>>
>>> Duncan
>
>

Report message to a moderator