Can anyone confirm if or add some insight to why versioning is broken?
Since Jan. 06 (v3.1.1), there's been an unassigned issue HHH-1401 saying
that versions are updated unnecessarily on merge. At least three other
issues have been added with similar problems for delete and in general
with Per
No patch that I know of. More than happy to work on one, but like I
said, any confirmation, insights, or discussion would be welcome first.
~Josh.
Steve Ebersole wrote:
Sorry, I must have missed the patch implementing the fix. Where do I
find that again?
-Original Message-
Can anyone
riginal Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Josh Moore
Sent: Thursday, August 24, 2006 1:25 PM
To: hibernate-dev@lists.jboss.org
Subject: [hibernate-dev] Possible to confirm that versioning is broken
forPersistentSets?
Can anyone confirm if or add some insight to
finally, what
to do with the Iterators?
~Josh.
Max Rydahl Andersen wrote:
On Tue, 29 Aug 2006 00:45:52 +0200, Josh Moore <[EMAIL PROTECTED]> wrote:
Sorry, myself, if there's nothing more anyone can say to versions
being broken. Without input, though, I'll assume it's easie
Ok. The isDirty()/write()/add()/clearDirty() idiom explains why the
patch was producing NPEs in other tests. Otherwise, the only other
failures that seemed they could be related were from the optlock tests.
Two were failing earlier (see
http://opensource.atlassian.com/projects/hibernate/secure/
Got the fixes in r10470. Thanks. I updated HHH-1668 -- PList and PBag
still have issues (failing tests). I can add a patch if you don't have
it local, Steve. The failing tests I had for PMap have apparently been
fixed.
I'm also having problems again with HHH-1401. Added a test (see link
below
Max Rydahl Andersen wrote:
if there are additions/removals to the collection then yes.
The reason being that the actual collections are considered value types
of the entity.
If you don't want optimistic locking to fire here then set
optimistic-lock="false" on the association.
Thanks Max. The
Steve Ebersole wrote:
Without having had a chance yet to look, what exactly are the proposed
changes in regards to lists and bags?
The changes are identical to PersistentSet omitting the add* methods.
I.e. clear, remove, removeAll, and retainAll all use the idiom:
initialize(true)
if ( list
Redirecting to list.jboss.org from sf.net
For truly efficient clustering of extended persistence contexts in the
context of Seam or EJB3, we need a way to propagate unflushed
changesets. What we need is an SPI like this:
Serializable changeset = session1.getChangeSet();
session2.applyCha
Using Hibernate with non-updatable fields can leave entities in a
confused state.
Take an Image with a field creationEvent, not updatable. If
Image.creationEvent is set on an instance and passed to session.merge(),
then:
(1) Properly, no UPDATE is issued.
(2) DefaultMergeEventListener.copy
nt with the way saveOrUpdate works
Josh Moore wrote:
Using Hibernate with non-updatable fields can leave entities in a
confused state.
Take an Image with a field creationEvent, not updatable. If
Image.creationEvent is set on an instance and passed to session.merge(),
then:
(1) Properly, no UPDAT
e, and you will see that
merge is very consistent.
Josh Moore wrote:
Emmanuel, do you mean saveOrUpdateCopy? Since saveOrUpdate doesn't do
any copying of the values onto another instance.
By the way, the "dirtying" of the non-updatable field I described also
holds fo
Sorry, Christian, didn't get your emails because of a delayed digest
message. And I agree that it can be seen as reasonable behavior. With
saveOrUpdate (as Emmanuel was pointing out) one gets
* in DB: no change
* in memory: (invalid) change
and with these semantics for merge:
* in DB: no
13 matches
Mail list logo
