|
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 |