On Saturday, June 30, 2012 2:49:56 AM UTC-4, Lukas Eder wrote: > > 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? >
That's true. I could create a separate metadata package to satisfy this requirement but it makes more sense (to me) that all of the metadata is kept in one place. Related to all of this, I also need the ability to determine the PK of each table, and I didn't see any way to get that information from the metadata. If it's really not there, my metadata generator can easily add an accessor for that information but then I'll be typecasting Table to MyTable every time I need my special metadata. What do you think about adding PK info to the jooq metadata? > 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 > I understand. I can get around it pretty easily but I feel dirty doing it. ~S
