On Mar 20, 2004, at 5:49 PM, Andrus Adamchik wrote:
>
> On Mar 20, 2004, at 5:32 PM, Mike Kienenberger wrote:
>
>>> 4. Refactored DataNode.runBatchUpdateAsIndividualQueries to remove
>>> redundant code, since the flow is essentially the same no matter
>>> whether the locking is used or not.
>>
>> The trick in DataNode.runBatchUpdateAsIndividualQueries was that
>> optimistic-locking code required query.next before each sql string
>> creation.
>
> Didn't realize that. Is this because of "x = ?" vs. "x is null"? Then
> there is not much we can do about. I guess we may need to change it
> back.
Or can we? I hate to change DataNode flow too much because of this. I
think we should partition UPDATES with different NULL positions into
separate queries at ContextCommit level.
To make things more simple... Do we really care to support true batch
updates for the queries that are using locking? If not, we can generate
a single update query per row for the case above and also stop worrying
about generic batch support.
My take on it is that while INSERT and DELETE batches are quiet useful,
UPDATE batches have very small size in most cases anyway. Anyone can
think of a common scenario when there is a need to update a large
number of objects at the same time (and with optimistic locking) that
fit in the same query batch template?
Andrus
This archive was generated by hypermail 2.0.0 : Sat Mar 20 2004 - 18:22:50 EST