> > Given that "getUpdateCount" result is correct, or we can make it
> correct (I don't completely understand the problems you are having
> with it),
>
> just a nasty bug. If you call getUpdateCount twice, you get
> a "-1" - and this is not resetted by "executeBatch". So if
> you do:
> executeBatch()
> getUpdateCount()
> addBatch()
> addBatch
> executeBatch()
> getUpdateCount()
>
> then this second getUpdateCount yields -1
"OracleStatement.noMoreUpdateCounts" field has default access (so it is
package-visiable), so are you creating a dummy class in oracle.jdbc.driver
package to get access to this variable?
Not sure if we can distribute such extension with Cayenne. I know that Sun
license explicitly prohibits adding classes to "java" package. Oracle may
have a similar licensing provision. As recent events show, we have to pay
serious attention to such issues.
> > In the worst case scenario, if a batch consists of
> > thousands of rows, and a primary key is compound
> > (so that IN() can't be used), WHERE clause is gonna
> > be *very* long.
>
> thats precicly what we do in the "PrefetchHelper"
> and the batch sizes are chosen such that the
> queries are not too long...
So we will need to partition batches. I have no problem with that, esp. if
there is a way in the code to configure these settings. Also,
OracleAdapter is the only adapter that has batching turned on currently. I
guess we need to test if any other drivers implement batching at all, and
hopefully if they do, they don't force users to go through all this
nonsense.
In other words, we need to support those other (sane) cases of simpler and
more efficient checking of optimistic lock failures from update counts
(batched or not).
Appreciate you volunteering to work on that. Once you have something to
check in, we should probably discuss whether we should fork a STABLE
branch in CVS for 1.0.
If we branch, STABLE will contain bug fixes for 1.0. HEAD will become a
1.1 branch. This way all major new changes will not destabilize 1.0. Of
course this means more maintenance. But this will give a chance to all our
eager committers to start working on the new and cool stuff :-)
Andrus
This archive was generated by hypermail 2.0.0 : Tue May 27 2003 - 10:59:22 EDT