|
|
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
|
|
|
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
>
>
|
|
|
|
Re: [Teneo] : VersionPropertyHandler returns null for dettached objects [message #607001 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
|
|
|
Re: [Teneo] : VersionPropertyHandler returns null for dettached objects [message #607004 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
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03339 seconds