Mike Matrigali wrote:
This looks like a reasonable fix, it would be nice if you added a test
case which showed the problem (to make sure it does not get broken again
in the future). If it were me I would add a short new test case to the
T_AccessFactory tests in
opensource/java/testing/org/apache/derbyTesting/unitTests/store. I know
you have a test case you can't check in as it is the feature you are
working on. If you are not interested in doing this, let me know.
Hi,
I have now updated one of the testcases in T_AccessFactory to test this
problem, and it reproduced the nullpointerexception (when running on
unpatched derby)
I also noticed that after my patch, the method:
boolean fetch(
RowLocation loc,
DataValueDescriptor[] row,
FormatableBitSet validColumns )
is functionally equivalent to:
boolean fetch(
RowLocation loc,
DataValueDescriptor[] row,
FormatableBitSet validColumns,
boolean waitForLock=true)
Previously, this bug had been fixed in the first method, not the other.
To improve code-reuse, I would like to implement:
fetch(
RowLocation loc,
DataValueDescriptor[] row,
FormatableBitSet validColumns )
as:
{
return fetch(loc, row, validColumns, true /* waitForLock */ );
}
.. unless there are any good reasons not to do it.
Andreas
