> We have an xml file that describes our DB schema. As well, it describes > meta information that will be needed by an ExecuteListener. My plan is to > write my own metadata generator, that drives of the xml file (vs a live DB > server). It would generate largely the same content as the jooq generator > does but instead of TableFieldImpl instances for each field, it would > MyTableFieldImpl instances. That would necessitate making TableFieldImpl > public. Note that TableImpl is already public.
While I'm generally interested in seeing how a metadata generator that generates classes from XML works (see the roadmap: https://sourceforge.net/apps/trac/jooq/ticket/911 and similar ones), I'm wondering if you need MyTableFieldImpl only to identify relevant fields, or if you will eventually add functionality to those fields. Instead of generating that logic into jOOQ's meta data, you could also access that XML from your ExecuteListener and do the checks there? I'm a bit reluctant to open up this implementation to public as you may have noticed. While it would be immediately useful to you, other users would find themselves with yet another implementation fact "leaked" to the public API > In another use case, our ExecuteListener will need to add some extra WHERE > clauses to certain queries. It may seem bizarre, but that's what our > current infrastructure does so we'll need to maintain that if we switch to > jooq. It will be nice to see that working! >> That probably makes sense. I filed this as feature request #1492: >> https://sourceforge.net/apps/trac/jooq/ticket/1492 > > What is the typical process from feature request to getting on the roadmap? It informally works like this: 1. You suggest something on the user group 2. If I generally like the idea, it gets on the roadmap 3. If I really like the idea or someone else also supports it on the user group, I'll eventually implement it when I have time There's no formal process, however. >> I'll see what other internals can be exposed in the public non-DSL API > > I need a way to see the field/value pairs for an INSERT query. That appears > to be getValues(). Yes, that's what I thought. Cheers Lukas
