Menu
▾
▴
springframework-developer
|
From: David S. <ds...@mi...> - 2004-10-19 17:10:31
|
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 |
|
From: Rod J. <ro...@in...> - 2004-10-19 18:10:33
|
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 > -- ____________________________________________________ Rod Johnson Interface21 - Spring Services from the Source http://www.springframework.com Founder, Spring Framework: http://www.springframework.org Author, "Expert One-on-One J2EE Development Without EJB" (May 2004, with Juergen Hoeller). http://www.amazon.com/exec/obidos/ASIN/0764558315/ Author, "Expert One-on-One J2EE Design and Development" (October 2002). http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/ ____________________________________________________ Interface21 Limited Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY Registered in England and Wales No. 5187766 ____________________________________________________ |
|
From: David S. <ds...@mi...> - 2004-10-19 20:19:09
|
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 >> > |
|
From: Rod J. <ro...@in...> - 2004-10-20 08:10:10
|
> OH, that's surprising to me. I missed that comment in the Javadoc which > says the same, more or less. > > (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. Sure, there's a choice here. Use JdbcTemplate if you prefer that. SqlQuery and other classes in that tree are intended to abstract a bit farther from JDBC. That's often, but not always, appropriate. > (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. Making them protected would be a valid option. However, the present design allows the choice of using the generic method. From the Javadoc: "Subclasses can either rely on one of these inherited methods, or can add their own custom execution methods, with meaningful names and typed parameters. Each custom query method will invoke one of this class's untype query methods." > > (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. It's threadsafe after initialization is complete, which is what matters. I've updated the Javadoc to make that clearer, although I think it's already fairly obvious. Rgds Rod |
