Just some thoughts I had on this subject.
Looks wrong to me to use the versioning of Hibernate to manage an
application versioning. I always split the 2 concepts and thus the 2
implementations.
This is especially true when reattaching objects. sometimes, reattaching
it will update the version nu
This seems to be a bug. Please submit to JIRA. TIA
St-Pierre Philip wrote:
I have a many-to-many association between two objects. The association
table contains the idbag identifier, the identifier of each associated
objects and additionnal fields (Collection of components). Here is the
associ
Christian Bauer wrote:
Right now, Hibernate will increment an entity version number whenever a
property of the entity is modified and the entity is being saved. This
is true for modifications of simple properties, components, many-to-one
relationships and even collections of value types and collec
What I meant is :
I do session.update(myobject);
Hibernate will always increase the version number.
But myobject properties may not have been updated for real (business
speaking), so no need to update the business version number.
Christian Bauer wrote:
On 22 Apr (14:16), Emmanuel Bernard wrote:
On 22 Apr (14:16), Emmanuel Bernard wrote:
> This is especially true when reattaching objects. sometimes, reattaching
> it will update the version number wo any "real" modification.
What is "sometimes"? :)
--
Christian Bauer
[EMAIL PROTECTED]
http://www.hibernate.org/
--
On 22 Apr (22:24), Gavin King wrote:
> Not true. If the collection is inverse="true", manipulating the
> collection does /not/ update the
> owner's version number!
I just tried A -one-to-many- B (bidi), inverse collection on A. Adding a
B to the collection, saving the A, I got an incremented ver
Hi Max, I've checked your build process.
Everything's fine. I only did update some minor stuffs :
- add the jdbc dir into the test classpath for metadata (same as
Hibernate)
- add the property files of src into the test classpath for metadata
(same as Hibernate)
- remove ehcache.xml from the d
hi,
in short: can i achive from an interceptor that entities that implement
Auditable and are (directly/indirectly) passed to saveOrUpdate() will
automatically be saved into a new row?
any hints how to implement in Hibernate for a patch candidate?
I was told to use triggers what I would like to
I have confirmed this. It is not intended behavior.
PersistentCollectionType.isDirty()
DirtyCollectionSearchVisitor
should both check that the collection is not inverse="true" before
returning true.
Add it to TODO list.
Christian Bauer wrote:
On 22 Apr (22:24), Gavin King wrote:
Not true
On 23 Apr (04:10), Gavin King wrote:
> I have confirmed this. It is not intended behavior.
>
> PersistentCollectionType.isDirty()
> DirtyCollectionSearchVisitor
>
> should both check that the collection is not inverse="true" before
> returning true.
>
> Add it to TODO list.
I still think th
Apparently, we have been exploiting the bug where changes to inverse
relationships do affect the modified version timestamp. I think it would
be useful to indicate whether you want changes to the relationship to
update the owner's timestamp independently of whether the relationship is
inverse
What are you are trying to do requires dealing (at the very least)
with these issues:
- What are you going to do with primary keys?
The simplest thing is to generate a new id. But then the auditing
mechanism must have a way of associating the new id with the old id.
Presumably that table would loo
12 matches
Mail list logo
