>
> > We found the following solution: 
> > 1. Add private List<ExecuteListener> executeListeners; 
> > with setters/getters to Factory.java 
> > 2. 
> > Add 
> >> 
> >>     List<ExecuteListener> getExecuteListeners(); 
> >> 
> >>     void setExecuteListeners(List<ExecuteListener> listeners); 
> > 
> > to  Configuration.java 
>


I have written a patch which uses composition over inhertiance. All objects 
now have a reference to the configuration instead of inheriting from it. 
That makes a lot of code much more simple and allows to get rid of many 
constructors and some methods. The patch for ExecuteListeners would fit 
perfectly into the new approach.

You can find the patch here: 
https://github.com/digulla/jOOQ/commit/96fa3b5e918dff6e5aa57a940a3490df8db05147

Note that it depends on the ConnectionProvider which is in this commit: 
https://github.com/digulla/jOOQ/commit/182d8a293c7633d1e31f64fa6a108813f0a89368

The second commit allows to use any kind of provider to get a connection - 
at lest it should. Right now, the source of the connection leaks into 
several places in the jOOQ codebase (DataSourceConnection, ConnectionProxy, 
DataSourceStatement, ...). My approach avoid this. You just ask the 
Configuration for the connection provider which gives you the connection.

The only open end here is that I don't know where jOOQ closes the 
connections that it got from the DataSource but Lukas can probably add the 
call to ConnectionProvider.close() in a few minutes.

Now back to the meat. Instead of inheriting from Configuration, I pass a 
reference to a Configuration around, possibly wrapping an existing 
Configuration when necessary. So instead of 5-6 constructors, the DB 
specific factories just have two:

    public H2Factory(Configuration configuration) {
        super(new DefaultConfiguration(configuration, SQLDialect.H2));
    }
    public H2Factory() {
        super(new DefaultConfiguration(SQLDialect.H2));
    }

In the default constructor, you could also use a value instance of 
Configuration. But since I'm unsure whether this patch has any chance to be 
included in the release, I didn't want to spend move than 8 hours on it.

There are these questions left:

1. When do I pass the configuration on and when do I clone?

2. When I clone, how deep do I clone? Should I clone the 
ConnectionProvider, too? How about the data map? Settings?

3. Factory has a method "attach" which I don't understand. The original 
code was:

    attachable.attach(this);

Now, it is:

    attachable.attach(configuration);

which might be wrong.

Comments?

Regards,

A. Digulla

Reply via email to