Hi Aaron, > If you look at the code, you'll see that it doesn't make sense. It would be > simple to get rid of the ConnectionProvider since only Configuration uses > it. But if I hadn't added it, there would be no chance for you to even look > at the idea.
OK, I understand. > Every application out there and every framework has their own GREAT IDEA(TM) > how to get a connection from JDBC. And you're adding one more :-) > No one uses the JDBC API directly; they > use Spring or Hibernate or Transaction managers or JNDI or whatnot. I was under the impression that using JNDI to look up a JDBC DataSource is the way to go in J2EE. And that using Spring API to look up a DataSource is the way to go in Spring. On popular request, I added the convenience of being able to use JDBC DataSources to jOOQ. Sergey's examples on the user group show how simple it is to configure a jOOQ Factory using Spring. I'm not sure why you imply that jOOQ has its own "GREAT IDEA(TM)". java.sql.DataSource seems to me to be a standard and well-understood way to handle what you call a ConnectionProvider. Or, in your own words, instead of adding yet another "GREAT IDEA(TM)", I prefer to go with the standard, which is JDBC. > Yes, it would be great if they simply gave you the connection. But they > don't. Who is "they"? > Everyone tries to be smart. So my solution is to wrap all this > b****** in a single place to prevent frameworks and applications from > leaking into jOOQ. Was it something I said? :-) > If you want to add JNDI support, instead of adding yet another constructor > to Factory and everything that extends it, you write a > JndiConnectionProvider. If you have Sping, you can write a > JdbcTemplateConnectionProvider or use the DefaultConnectionProvider. If you > use Hibernate, ... you get the idea. I get the idea, yes. > As you can see, your approach is to add N*M constructors while my approach > uses a single constructor and an interface which defines how jOOQ > communicates with the outside world. So far, I wasn't aware of the fact that the 5 Factory constructors in jOOQ 2.3 and the 6 Factory constructors jOOQ 2.4 were a problem to any user. Constructor overloading for convenience seems to be a quite common practice to me. Example: java.util.HashMap (4 constructors) > Having JDBC API compatibility is just an additional bonus. With #1498 fixed, I can compile jOOQ with JDK 6 and 7 > OO imposes some limitations on us and Java even more so. Someone thought > that interfaces are a great idea and now, we have to live with it. But is it > really better to add a new set of constructors for every connection source? > > How did you plan to add JNDI support to jOOQ? I won't add JNDI support to jOOQ > You can create a configuration in the existing constructors and deprecate > them. I didn't because I wanted to demonstrate the effect. OK >> I'm not sure why cloning of Configuration attributes should be done...? > > That depends on the life cycle of the configuration. If you pass a Oracle > configuration to H2Factory, the dialect must be replaced. If you simply > changed it without cloning, Oracle won't be happy later. Good point. Moving the SQLDialect out of the Factory, into the Configuration would mean that H2Factory will be somewhat obsolete. At least its stateful part, the static methods providing access to H2-specific functionality will remain. > In that case, my change is correct but maybe it would be better to add a > counter to the DataSourceConnectionProvider to make sure the connection is > only closed after the last piece of code is done with it. Hmm, I currently do not have a test case for that. But I'm assuming that the current design is correct. 1. If jOOQ operates on a JDBC Connection, that connection must be closed in client code 2. If jOOQ operates on a JDBC DataSource, then that DataSource is wrapped in a DataSourceConnection, which pretends that it actually is a Connection. Every time a statement execution is finished, the delegate Connection, which was fetched from the wrapped DataSource is closed. When another statement is executed on the same DataSourceConnection, jOOQ retrieves a new delegate Connection from the wrapped DataSource. These facts are hidden from jOOQ's internals, so jOOQ doesn't notice the difference between 2. and 1. Cheers Lukas
