John McNally wrote: > On Mon, 2002-05-06 at 09:05, Bill Schneider wrote: > >>I made a patch locally to allow me to use DataSources from JNDI instead of >>the default Torque connection pool. I used the Adapter pattern (I think >>that's the word for it :-)) to preserve backward compatibility, turning >>pool/DBConnection and pool/ConnectionPool into interfaces and copying the >>existing classes to ConnectionPoolImpl and DBConnectionImpl. Then I added >>two new classes, DataSourceWrapper (implements ConnectionPool) and >>ConnectionWrapper (implements DBConnection), which wrap a DataSource and a >>java.sql.Connection and adapt them to the Torque APIs. >> >>I also touched Torque.java to let me specify a database like >> >>database.mydatabase.resource=jdbc/MyDataSource >> >>There are three questions that I'd like to discuss here on this list -- >> >>- is this a reasonable approach? It seems like it would be better for all >>Torque code to use java.sql.Connection and javax.sql.DataSource directly, >>and eliminate ConnectionPool/DBConnection entirely, since JDBC 2 is the >>standard. This would break existing code, though, because all the generated >>classes expect Torque.getConnection() to return a DBConnection instead of a >>java.sql.Connection. > > > I created a branch, JDBC2POOL_BRANCH, to do this work. I was planning > to merge this post 3.0 release. But the release process is moving very > slowly. Maybe it would be better to eliminate DBConnection prior to the > release?
+1 martin > > >>- is there a good way to find out, at runtime, what database you're >>connecting to? When all you have is a DataSource and a JNDI resource name, >>you have no way of knowing the underlying database, which Torque needs to >>know to pick the right database adapter. Is there some magic JDBC query or >>escape that lets you figure out your database? (conn.getClass() doesn't >>work because it is usually wrapped by the pool, e.g., >>org.apache.commons.dbcp.PoolableConnection) >> > > > I just introduced a property to specify the database type or adapter. > This used to be specified separately from the driver property and tying > them together has caused about as many questions as having the two > properties. As you point out there is no way (or we have been unable to > find a way) to keep the mapping using datasources. > > >>- administrivia: what's the right way to submit a patch if there are new >>files that weren't in CVS before? >> > > > Adding them as separate attachments is fine. > > john mcnally > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
