RE: [hibernate-dev] Possible to confirm that versioning is broken forPersistentSets?
by Steve Ebersole
I've made some changes here locally which attempt to group fixes to a
bunch of these seemingly related issues. So for PersistentSet.add()
(for example), I have:
public boolean add(Object value) {
Boolean exists = isOperationQueueEnabled() ?
readElementExistence(value) : null;
if ( exists == null ) {
boolean initiallyDirty = isDirty();
write();
boolean actuallyAdded = set.add( value );
if ( !actuallyAdded ) {
if ( ! initiallyDirty && isDirty() ) {
clearDirty();
}
}
return actuallyAdded;
}
else if ( exists.booleanValue() ) {
return false;
}
else {
queueOperation( new SimpleAdd(value) );
return true;
}
}
But I need to get time to properly test these changes before I commit
them.
-----Original Message-----
From: Josh Moore [mailto:josh.moore@gmx.de]
Sent: Thursday, August 31, 2006 7:35 AM
To: Max Andersen
Cc: Steve Ebersole; hibernate-dev(a)lists.jboss.org;
koda2(a)bbs.darktech.org
Subject: Re: [hibernate-dev] Possible to confirm that versioning is
broken forPersistentSets?
Actually had meant doing this in application code. Glad I didn't start.
Thanks to the patch on HHH-1668 from Koda Janh, I could get the HHH-1401
test passing. Had to add a protective if-clause around the write
statement in PeristentSet.clear() similar to Koda's in
PersistentSet.add()/addAll()/remove()/removeAll()/retainAll(). The same
needs to be done for most of the PersistentCollection methods which use
write.
I've got additions to Koda's patch for clear() and PersistentList. I can
take it farther for Map and co., but I saw, Steven, that you changed the
fix version to 3.2.1 for the group of bugs; have you made the changes
already or should I keep extending patch?
A few questions : for all the PersistentCollections which hold a
Collection implementation, these calls could be pushed up into
AbstractPersistentCollection. Is it worth the effort? And finally, what
to do with the Iterators?
~Josh.
Max Rydahl Andersen wrote:
> On Tue, 29 Aug 2006 00:45:52 +0200, Josh Moore <josh.moore(a)gmx.de>
wrote:
>
>> Sorry, myself, if there's nothing more anyone can say to versions
>> being broken. Without input, though, I'll assume it's easier to roll
>> our own.
>
> If you by "roll our own" means make a fix for it then we would of
course
> be interested in it.
>
> As with all existing issues we need to prioritize them and issues with
> patches
> has a very high tendency to be fixed before issues without patches.
>
> /max
>
>>
>> Thanks,
>> ~Josh
18 years, 3 months
RE: [hibernate-dev] Possible to confirm that versioning is broken forPersistentSets?
by Steve Ebersole
Yes, you've missed something...
Your patch does absolutely nothing to ensure that the underlying
collection is loaded. That's the reason Josh see's
NullPointerExceptions from the test suite when using your patch (the
underlying set is null because it has not been initialized).
I would guess you are getting caught up in the name rather than actually
looking at what write() does.
-----Original Message-----
From: cowwoc [mailto:cowwoc@bbs.darktech.org]
Sent: Thursday, August 31, 2006 8:36 AM
To: Steve Ebersole
Cc: Josh Moore; Max Andersen; hibernate-dev(a)lists.jboss.org;
koda2(a)bbs.darktech.org
Subject: Re: [hibernate-dev] Possible to confirm that versioning is
broken forPersistentSets?
Just curious why you're doing all this initiallyDirty business
instead
of using the patch I've uploaded which ensures write() is only invoked
if it has to be. Seems safer and simpler to me, or have I missed
something?
Thanks,
Gili (Koda2)
Steve Ebersole wrote:
> I've made some changes here locally which attempt to group fixes to a
> bunch of these seemingly related issues. So for PersistentSet.add()
> (for example), I have:
>
>
> public boolean add(Object value) {
> Boolean exists = isOperationQueueEnabled() ?
> readElementExistence(value) : null;
> if ( exists == null ) {
> boolean initiallyDirty = isDirty();
> write();
> boolean actuallyAdded = set.add( value );
> if ( !actuallyAdded ) {
> if ( ! initiallyDirty && isDirty() ) {
> clearDirty();
> }
> }
> return actuallyAdded;
> }
> else if ( exists.booleanValue() ) {
> return false;
> }
> else {
> queueOperation( new SimpleAdd(value) );
> return true;
> }
> }
>
> But I need to get time to properly test these changes before I commit
> them.
>
>
> -----Original Message-----
> From: Josh Moore [mailto:josh.moore@gmx.de]
> Sent: Thursday, August 31, 2006 7:35 AM
> To: Max Andersen
> Cc: Steve Ebersole; hibernate-dev(a)lists.jboss.org;
> koda2(a)bbs.darktech.org
> Subject: Re: [hibernate-dev] Possible to confirm that versioning is
> broken forPersistentSets?
>
> Actually had meant doing this in application code. Glad I didn't
start.
> Thanks to the patch on HHH-1668 from Koda Janh, I could get the
HHH-1401
>
> test passing. Had to add a protective if-clause around the write
> statement in PeristentSet.clear() similar to Koda's in
> PersistentSet.add()/addAll()/remove()/removeAll()/retainAll(). The
same
> needs to be done for most of the PersistentCollection methods which
use
> write.
>
> I've got additions to Koda's patch for clear() and PersistentList. I
can
>
> take it farther for Map and co., but I saw, Steven, that you changed
the
>
> fix version to 3.2.1 for the group of bugs; have you made the changes
> already or should I keep extending patch?
>
> A few questions : for all the PersistentCollections which hold a
> Collection implementation, these calls could be pushed up into
> AbstractPersistentCollection. Is it worth the effort? And finally,
what
> to do with the Iterators?
>
> ~Josh.
>
> Max Rydahl Andersen wrote:
>> On Tue, 29 Aug 2006 00:45:52 +0200, Josh Moore <josh.moore(a)gmx.de>
> wrote:
>>> Sorry, myself, if there's nothing more anyone can say to versions
>>> being broken. Without input, though, I'll assume it's easier to roll
>>> our own.
>> If you by "roll our own" means make a fix for it then we would of
> course
>> be interested in it.
>>
>> As with all existing issues we need to prioritize them and issues
with
>
>> patches
>> has a very high tendency to be fixed before issues without patches.
>>
>> /max
>>
>>> Thanks,
>>> ~Josh
18 years, 3 months
RE: [hibernate-dev] Possible to confirm that versioning is broken forPersistentSets?
by Steve Ebersole
Oops:
protected void configure(Configuration cfg) {
super.configure( cfg );
cfg.setProperty( Environment.BATCH_VERSIONED_DATA,
"false" );
}
The reasoning being that certain drivers (oracle and db2 that I know of)
report an "unknown" status for these update and deletes when they are
batched (no idea why...). "unknown" is not considered a failure...
-----Original Message-----
From: Steve Ebersole
Sent: Thursday, August 31, 2006 8:43 AM
To: 'Josh Moore'
Cc: hibernate-dev(a)lists.jboss.org
Subject: RE: [hibernate-dev] Possible to confirm that versioning is
broken forPersistentSets?
OptimisticLockTest was failing on certain databases because the test was
poorly written; it was relying on my local setting of not using
statement batching for versioned data. I have updated the test to
explicitly disable batching of versioned data.
Try adding the following to your local copy and see if that fixes the
error you see. If not open a JIRA case with the failure, as that would
be a bug.
-----Original Message-----
From: Josh Moore [mailto:josh.moore@gmx.de]
Sent: Thursday, August 31, 2006 8:10 AM
To: Steve Ebersole
Cc: Max Andersen; hibernate-dev(a)lists.jboss.org; koda2(a)bbs.darktech.org
Subject: Re: [hibernate-dev] Possible to confirm that versioning is
broken forPersistentSets?
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/attachment/125
60/TEST-org.hibernate.test.optlock.OptimisticLockTest.txt)
but all are failing with the patch, e.g.:
Testcase: testOptimisticLockAllDelete took 0.134 sec
Caused an ERROR
Batch update returned unexpected row count from update [0]; actual row
count: 0; expected: 1
~Josh.
Steve Ebersole wrote:
> I've made some changes here locally which attempt to group fixes to a
> bunch of these seemingly related issues. So for PersistentSet.add()
> (for example), I have:
>
>
> public boolean add(Object value) {
> Boolean exists = isOperationQueueEnabled() ?
> readElementExistence(value) : null;
> if ( exists == null ) {
> boolean initiallyDirty = isDirty();
> write();
> boolean actuallyAdded = set.add( value );
> if ( !actuallyAdded ) {
> if ( ! initiallyDirty && isDirty() ) {
> clearDirty();
> }
> }
> return actuallyAdded;
> }
> else if ( exists.booleanValue() ) {
> return false;
> }
> else {
> queueOperation( new SimpleAdd(value) );
> return true;
> }
> }
>
> But I need to get time to properly test these changes before I commit
> them.
18 years, 3 months
RE: [hibernate-dev] Possible to confirm that versioning is broken forPersistentSets?
by Steve Ebersole
OptimisticLockTest was failing on certain databases because the test was
poorly written; it was relying on my local setting of not using
statement batching for versioned data. I have updated the test to
explicitly disable batching of versioned data.
Try adding the following to your local copy and see if that fixes the
error you see. If not open a JIRA case with the failure, as that would
be a bug.
-----Original Message-----
From: Josh Moore [mailto:josh.moore@gmx.de]
Sent: Thursday, August 31, 2006 8:10 AM
To: Steve Ebersole
Cc: Max Andersen; hibernate-dev(a)lists.jboss.org; koda2(a)bbs.darktech.org
Subject: Re: [hibernate-dev] Possible to confirm that versioning is
broken forPersistentSets?
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/attachment/125
60/TEST-org.hibernate.test.optlock.OptimisticLockTest.txt)
but all are failing with the patch, e.g.:
Testcase: testOptimisticLockAllDelete took 0.134 sec
Caused an ERROR
Batch update returned unexpected row count from update [0]; actual row
count: 0; expected: 1
~Josh.
Steve Ebersole wrote:
> I've made some changes here locally which attempt to group fixes to a
> bunch of these seemingly related issues. So for PersistentSet.add()
> (for example), I have:
>
>
> public boolean add(Object value) {
> Boolean exists = isOperationQueueEnabled() ?
> readElementExistence(value) : null;
> if ( exists == null ) {
> boolean initiallyDirty = isDirty();
> write();
> boolean actuallyAdded = set.add( value );
> if ( !actuallyAdded ) {
> if ( ! initiallyDirty && isDirty() ) {
> clearDirty();
> }
> }
> return actuallyAdded;
> }
> else if ( exists.booleanValue() ) {
> return false;
> }
> else {
> queueOperation( new SimpleAdd(value) );
> return true;
> }
> }
>
> But I need to get time to properly test these changes before I commit
> them.
18 years, 3 months
RE: [hibernate-dev] Connection proxying
by Steve Ebersole
Then we need @bad... ;)
-----Original Message-----
From: hibernate-dev-bounces(a)lists.jboss.org
[mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Max Rydahl
Andersen
Sent: Wednesday, August 30, 2006 3:01 PM
To: Christian Bauer; hibernate-dev(a)lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
>> The question was simply whether exposing the
>> Work/command APIs justify removal of the connection() method from the
>> perspective of using it for direct JDBC work. I do not know that
answer
>> to that. Unfortunately, I suspect it does not and that we will need
to
>> keep connection() around; but one can dream.
>
> I'd keep connection() around and not deprecate it, no matter what
better
> solutions we find for the various use cases. We can hide it in the API
> documentation and like we do now, document the problems. It's just too
> useful to deprecate it. Also remember the public riots when JDO 1.0
> didn't have an easy way to get a JDBC connection.
I agree this is also a reason/same reason to keep it, but I do think (at
least for now ;) that
@deprecate would make sense.
Not @deprecate as in "it will be removed", but @deprecate as how it is
done for e.g. Date and some of its constructors.
Those constructors are still around because they are usable in some
contexts but with @deprecate it is made explicit and documented
that they are 'bad' and what the consequences are for using it.
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
18 years, 3 months
