| [Teneo] : VersionPropertyHandler returns null for dettached objects [message #86580] |
Sat, 16 June 2007 11:57  |
Eclipse User |
|
|
|
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
|
|
|
|
| Re: [Teneo] : VersionPropertyHandler returns null for dettached objects [message #86611 is a reply to message #86596] |
Sat, 16 June 2007 17:03  |
| Eclipse User |
|
|
|
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
|
|
|
| Re: [Teneo] : VersionPropertyHandler returns null for dettached objects [message #86653 is a reply to message #86611] |
Mon, 18 June 2007 05:32 |
| Eclipse User |
|
|
|
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
>
>
|
|
|
| Re: [Teneo] : VersionPropertyHandler returns null for dettached objects [message #607000 is a reply to message #86580] |
Sat, 16 June 2007 13:57 |
| Eclipse User |
|
|
|
...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
|
|
|
| Re: [Teneo] : VersionPropertyHandler returns null for dettached objects [message #607001 is a reply to message #86596] |
Sat, 16 June 2007 17:03 |
| Eclipse User |
|
|
|
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
|
|
|
| Re: [Teneo] : VersionPropertyHandler returns null for dettached objects [message #607004 is a reply to message #86611] |
Mon, 18 June 2007 05:32 |
| Eclipse User |
|
|
|
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
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.05114 seconds
Home