On 22-11-2012 13:16, the_a_rioch wrote:

>>>> will it re-create and re-prepare update statement on every call to update the row ? or will it be able to cache one prepared update statement and only substitute new parameters during the whole loop ?
>>>
>>> Former - on each row application might update different rows and we want
>>> to change only them. So the update statement is re-prepared each time.
>>
>> Looks like something that could be improved by only re-preparing if the
>> statement is different.
>
> Which in turn would encourage that lazy approach. Should such style be encouraged or discouraged ?
> You would still waste time on comparing "what had changed" between iterations.

I guess it is cheaper to make the comparison, than to waste a round trip
to the server to re-prepare. And as updatable resultsets are a fact and
clearly defined in the JDBC spec, I don't think we should consider it as
second-rate. That said, there are probably more important things to
consider.

> You would probably loose ability of bi-transactional work (while you can add some auxUpdatingTransaction field you would hardly make it reliable in all those automagic scenarios).

I am not sure what you mean with 'bi-transactional' work and why
changing resultset would make you loose that ability. There is no such
thing in Jaybird when using a single connection, so you don't have that
now when using updatable resultsets.

> So while this can be cached, IMHO in this regard "faster" means really "worse".
>
> ----
>
> I'm curious if JayBird could provide special kind of JDBC transaction splitting into two FB Transactions under the hood ? :-)

Technically we probably could as Firebird allows for it, but as JDBC
doesn't provide an API for that, I think it would be a relative waste of
time. I'd prefer getting a more complete and correct implementation of
JDBC before considering gold-plating the driver with all kinds of
Firebird specific extensions.

Mark
--
Mark Rotteveel