[Springframework-developer] Re: SqlQuery.execute() untyped parameter Object[]

[David S. <ds...@mi...>]

OH, that's surprising to me.  I missed that comment in the Javadoc which 
says the same, more or less.  I understand the suggested usage pattern 
better though examples would still be helpful in the javadocs.  This 
leaves me with more commentary:

(1) There's still the Object[] parameter values separated from setting 
the parameter types... though this can be localized to the SqlQuery 
subclass implementation you suggested.  setXXXX (where XXX is a type) 
style I think is preferred.

(2) If it's suggested that client code invoke this specialized method 
only, then shouldn't most of the methods in RdmsOperation on-up in the 
hierarchy be protected?  Having them public suggests that client code 
might want to touch them when they shouldn't be.  As it stands, if I 
don't want client code to have visibility of them, I'd need to create a 
small class that delegates to an SqlQuery instead of extends from it. 
It'd need to delegate setting the DataSource too.

(3) RdbmsOperation claims to be thread-safe but it isn't.  compile(), 
and all getters & setters should employ synchronization.  Alternatively, 
the false thread-safe claim could be eliminated.

I wonder what the rest of the Spring community thinks of the SqlQuery 
hierarchy design.

Cheers,
	Dave Smiley

Rod Johnson wrote:

> You're meant to subclass SqlQuery to add strongly typed methods with 
> meaningful names.
> 
> E.g. findAllSomethingOrOthers(int, String) would invoke the generically 
> typed execute() method in the superclass.
> 
> David Smiley wrote:
> 
>> Hello... I hope it's appropriate to post my comment to this list since
>> it's not a usage assistance issue (in which case I'd be sending this 
>> to the user list).
>>
>> I just started working on project here that uses Spring jdbc.core's
>> JdbcTemplate & the gang in that package. When I discovered the higher 
>> order abstractions in jdbc.object, it seemed to me that we should use 
>> those facilities. The lead developer of the project told me that he 
>> deliberately avoided it because he thought the *untyped* Object[] 
>> array to parameterize a query as found in SqlQuery.execute() was a 
>> very poor design choice. He preferred the interface and use of 
>> PreparedStatementSetter as used within jdbc.core. I tend to agree but I
>> still want to use the package anyway. I do see the declareParameter() 
>> and setTypes() methods of RdbmsOperation but this just separates the 
>> type determination from specifying the parameter values when it could 
>> be done at once (again, as with PreparedStatementSetter). Can the 
>> rationale between the Object[] parameterization in jdbc.object be 
>> explained, and perhaps could jdbc.object be reworked in the future to 
>> handle a PreparedStatementSetter or some similar typed parameter 
>> strategy?
>>
>> Thanks.
>>
>> ~ David Smiley
>> MITRE
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>> Use IT products in your business? Tell us what you think of them. Give us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
>> more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>