> In our code, we have an object which identifies the database, the
> caller and the thread making the call. It would be good if we could do
> something like:
> factory.setClientData("CallerInfo", callerInfo);Good idea. This would be useful also for people implementing custom QueryParts, as documented here: http://www.jooq.org/manual/JOOQ/Extend/ So org.jooq.Configuration would have two new methods: Object getData(String); void setData(String, Object); The method names might differ, as all factories inherit them, but I like the idea. > and in the strategy: [...] Actually, the strategy should receive a context object instead of the query. The context object will correspond to what you call "SqlQueryDebuggerData". It will contain the Query, the Factory (i.e. Configuration), and some other data. "CallerInfo" can then be reached via ------------------------------------------------------------------- PreparedStatement eventPrepareStart(EventContext context, PreparedStatement stmt) { CallerInfo info = (CallerInfo) context.getConfiguration().getClientData(); } ------------------------------------------------------------------- or even shorter as EventContext could extend Configuration, similar to the existing RenderContext and BindContext interfaces ------------------------------------------------------------------- PreparedStatement eventPrepareStart(EventContext context, PreparedStatement stmt) { CallerInfo info = (CallerInfo) context.getClientData(); } ------------------------------------------------------------------- > It is a concept that is present for example in UI APIs. Swing has > "JComponent.putClientProperty(Object, Object)" and SWT has > "Widget.setData(String, Object)" which are very convenient to avoid > decoupling an object and related information/state. Good examples. HTML5 has "custom data attributes", and XSD has <xs:appinfo>, etc. Cheers Lukas
