On Tue, 2012-04-24 at 17:00 +0200, Lukas Eder wrote: > Hello Murray, > > > As mentioned here: > > http://stackoverflow.com/questions/10264001/instantiating-a-jooq-field-by-name > > I am using jOOQ in some generic code, without using jOOQ's code > > generation. The table names and field names are not known until runtime. > > Thanks for sharing your thoughts. I agree that jOOQ lacks some sort of > convenient way of using arbitrary qualifiers as Field, Table, Schema, > Routine, and other entities. As I mentioned on that Stack Overflow > question, jOOQ actually relies on this itself, internally. But in the > public API, we need to give this a little more thought. > > > This would be nice, for instance: > > Factory.field("someparent", "somefield") > > where the parent parameter would be either the table name or an alias > > for the table, or an alias (such as an alias to a join to another > > table). > > Maybe it would need a DataType parameter too. > > Yes, optional Class<T> or DataType<T> parameters are always useful for > org.jooq.Field<T> constructors. The problem with the Factory.field() > method, however, is that it's already overloaded quite a bit. Your > suggestion would collide with Factory.field(String, Object...), which > is used for something entirely different. The same applies for > Factory.table(String, Object...). > > > And this would be nice too: > > Factory.tableByName("sometable") > > (There is already a table("SQL") method.) > > where the name would be either a table or an alias. > > Yes, maybe this little extra verbosity would be helpful for > disambiguation in this case. Or maybe: > > Schema Factory.qualifiedSchema(String...) > Table Factory.qualifiedTable(String...) > Field<?> Factory.qualifiedField(String...) > <T> Field<T> Factory.qualifiedField(Class<T>, String...) > <T> Field<T> Factory.qualifiedField(DataType<T>, String...) > > Or even: > > Name Factory.name(String) > > And then build Schemata, Tables, Fields using names: > > Schema Factory.schema(Name...) > Table Factory.table(Name...) > Field<?> Factory.field(Name...) > <T> Field<T> Factory.field(Class<T>, Name...) > <T> Field<T> Factory.field(DataType<T>, Name...)
Personally, I would prefer a clear simple API like tableByName() and fieldByName(). The indirection of a Name class would make the API a bit tedious, and there are already so many classes that seem to leak into the top-level API. > Another option is to use the existing API and enhance it compatibly. > Take Factory.field(String, QueryPart...) for instance: > http://www.jooq.org/javadoc/latest/org/jooq/impl/Factory.html#field%28java.lang.String,%20java.lang.Class,%20org.jooq.QueryPart...%29 > > It allows for a dedicated escape syntax for QueryPart placeholders > {0}, {1}, {2} and keywords {keyword}. This could be an option, as > well, to allow for [escaped names] I would prefer jOOQ to just do the right thing if I've told it what the table (or alias) name is and what the field name is. Telling it to use a particular escape syntax, or even having to tell it to use _a_ escape syntax, seem superfluous in a high-level public API. > Of course, all of these elements can be combined. > > Any other API ideas? > > > By the way, it looks like jOOQ strongly assumes that we will use its > > code generation. So much so that the documentation pages uses > > database-specific API (BOOK, BOOKSTORE, etc) that must have been > > generated, without explicitly mentioning that. In case people arrive at > > a page without reading the previous pages, it might be helpful to add a > > link to a description of the code generation, to each place where it is > > implicitly used. > > Yes, the very first section of the manual mentions the sample database, here: > http://www.jooq.org/manual/JOOQ/ExampleDatabase/ > > But you're right. I'll check how many references would be needed to > clarify that in the manual. If it's not a huge number, I could add > such a hint to all relevant paragraphs. Maybe even some sort of > footnotes...? I would add something like "This uses the classes that we generated in Step 2 (with a link)" near the top of pages such as this: http://www.jooq.org/tutorial.php#step2 And/or I might like a link to the actual class names in the example code. Actually, API links in the example code would be really useful, though that's a lot of work, and lots of links to keep up-to-date. -- [email protected] www.murrayc.com www.openismus.com
