Re: [Springframework-developer] newPreparedStatementCreator in SqlOperation has become final

[<jue...@we...>]

I agree that Thomas' suggestion sounds like the best solution for this =
problem. I also agree that the code from my last mail would effectively =
bypass SqlQuery's functionality... It was rather meant as "the least =
effort to make it work again".
=20
If you're using a custom ResultReader anyway, you could indeed subclass =
RdbmsOperation directly, invoking its JdbcTemplate with your custom =
PreparedStatementCreator and ResultReader. In terms of the functionality =
that you're actually using, that would be the most appropriate =
inheritance design. The various operation objects in the jdbc.object =
package are effectively just a thin layer on top of JdbcTemplate and =
other jdbc.core functionality anyway.
=20
As a side note, that "newPreparedStatementCreator" became final was =
actually a side effect of the introduction of the =
"newPreparedStatementSetter" method in SqlOperation. That new method was =
final from the start, so it seemed to me that the other one had to be =
to, judging from SqlOperation's purpose - building a =
PreparedStatementCreatorFactory. Unfortunately, I completely forgot to =
discuss this on the mailing list, as this happened in the middle of a =
bunch of stuff.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Tom Turelinckx
Gesendet: Fr 04.06.2004 00:07
An: spr...@li...
Betreff: Re: [Springframework-developer] newPreparedStatementCreator in =
SqlOperation has become final



Hi Juergen!

> Basically, you're bypassing all of SqlOperation's functionality when =
you
> use a custom PreparedStatementCreatorFactory. That's why I considered =
it
> a bug that "newPreparedStatementCreator" wasn't final before.

True, but I don't actually want to use a custom one, I just want to
customize the existing one a bit ;-) Thomas' suggestion sounds like a
good idea!

> wasn't a particular good idea to change that at this point of time,
> though - sorry for any inconvenience.

Never mind, I should have tested the cvs version before 1.0.2 was
released [shamefaced smiley here] ;-)

> What you can do is perform the query yourself rather than delegating =
to
> SqlQuery's execute method:

Hmm, wouldn't that be bypassing all of SqlQuery's functionality,
essentially? ;-)
As I'm also using a custom ResultReader (with range support), I can
probably just as well extend from RdbmsOperation directly...

Thanks for the suggestions!
Tom.


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer