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...)
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]
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...?
Cheers
Lukas
2012/4/24 Murray Cumming <[email protected]>:
> 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.
>
> To create a SQL query, I can use
> Factory.field("somefield")
> and
> factory.select(fields).from("sometable")
> but both those strings are just arbitrary SQL, not specifically field or
> table names. It would be great if I could specify these explicitly, to
> get the benefit of quoting, escaping, the "parent.field" syntax, and
> some protection against SQL injection. And I think that would be healthy
> for the API overall.
>
> 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.
>
> 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.
>
> 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.
>
> --
> [email protected]
> www.murrayc.com
> www.openismus.com
>
