Hi Timo,
I have given this another thought:
> The general approach of jOOQ feels quite good, but I believe that your
> usage of a static metamodel results in verbose alias constructs. Querydsl
> uses dynamic typed paths for everything, which is conceptually simpler and I
> believe in the end also syntactically lighter.
>
The reason I originally wanted a static meta model is to enable the use of
static imports. That's a minor but effective advantage for the "static"
approach, since you mention verbosity. Once that was established, I have
built aliasing around tables using the aforementioned
*getField(Field<?>)*methods. In my design, I wanted to absolutely
prevent users from
instanciating objects at any time using the *new *keyword. This is for two
reasons:
1. I have full control over the DSL and all objects jOOQ provides. This
doesn't mean, that custom objects are impossible. Every public interface (
*Condition*, *Field*, etc) can be implemented by client code if used
appropriately.
2. I suppose it will be easier to change jOOQ without breaking anything,
as more implementation logic is hidden.
But maybe these two ideas are not as relevant as I imagined...
To get back to aliasing: This design was necessary to allow for aliasing
inner selects (or similar constructs) such as:
SELECT a.x, a.z FROM (SELECT t.x, f(t.y) z FROM t) a
>
Which will be translated into something like (might not be entirely correct,
syntactically):
> Field<?> z = f(T.Y).as("z"); // f() in this case is a generated stored
> function...
> Table<?> a = create().select(T.X, z).from(T).asTable("a");
>
create().select(a.getField(T.X), a.getField(z)).from(a);
>
Of course the example makes little sense, it should just illustrate a
generic problem. How have you solved this aliasing a query and selecting
from it with QueryDSL? The problem here is that *a.x, a.z* cannot be known
in advance in any meta model. I have given quite some thought to these
things, and unfortunately, I couldn't come up with a less verbose
solution...
To decrease verbosity of my aliasing physical tables, however, I will
probably opt for generated member methods X() and Y() in the generated table
class T. These methods will invoke getField(X) or getField(Y) on the table.
The as(String) method on those tables will then return an object of the same
type as the table. Let's see how this continues!
Cheers
Lukas
