Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-06-03 15:32:26
|
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. Probably =
wasn't a particular good idea to change that at this point of time, =
though - sorry for any inconvenience.
What you can do is perform the query yourself rather than delegating to =
SqlQuery's execute method:
public class MySqlQuery extends SqlQuery {
public void myExecute(Object[] parameters) {
ResultReader rr =3D newResultReader(0, parameters, null);
return =
getJdbcTemplate().query(newMyPreparedStatementCreator(parameters), rr);
}
protected PreparedStatementCreator =
newMyPreparedStatementCreator(Object[] parameters) {
...;
}
}
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Tom Turelinckx
Sent: Thursday, June 03, 2004 4:31 PM
To: spr...@li...
Subject: [Springframework-developer] newPreparedStatementCreator in
SqlOperation has become final
Hello Juergen,
While upgrading all of our applications to Spring 1.0.2, I noticed
newPreparedStatementCreator() in SqlOperation has become final. Though
this is probably a good thing, I currently don't see an easy way to have
SqlOperation use a custom PreparedStatementCreatorFactory...
We have some queries (extending SqlQuery) that use sql parameters of =
type
ARRAY, e.g.:
new SqlParameter( "dg_ids", Types.ARRAY, "DISCHARGE.NT_DIS_IDS" )
and thus require a custom (Oracle-specific)
PreparedStatementCreator/Setter to do something like this:
case Types.ARRAY:
ps.setArray( idx, getOracleArray( con, declaredParam.getTypeName(),
param ) );
break;
private ARRAY getOracleArray( Connection con, String typeName, Object =
obj
) throws SQLException {
Connection nativeCon =3D getNativeConnection( con );
return new ARRAY( ArrayDescriptor.createDescriptor( typeName,
nativeCon ), nativeCon, obj );
}
I was overriding newPreparedStatementCreator() to force the use of my =
own
OraclePreparedStatementCreator, but this is no longer possible, and, in
fact, I don't see another way of accomplishing this...
Maybe compileInternal() in SqlOperation could delegate the creation of
preparedStatementFactory to a protected
"createPreparedStatementCreatorFactory" method?
Kind regards,
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
|
|
From: <jue...@we...> - 2004-06-04 08:15:25
|
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 |
|
From: Tom T. <tom...@pr...> - 2004-06-03 22:07:40
|
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. |
