I tried to think of a case where returning the union-query as table
would enable optimizations, but so far I couldn't come up with anything.
With the other approach, depending on the stage this optimization should
happen, it might be pretty simple to omit columns of table references
and further
I tried to think of a case where returning the union-query as table
would enable optimizations, but so far I couldn't come up with anything.
With the other approach, depending on the stage this optimization should
happen, it might be pretty simple to omit columns of table references
and further
I should have been more clear as to why this is a problem :)
The columns are resolved as the persisters are built. Later as we build
the SQL AST part of that process is resolving ColumnBindings. To do that
the Column is passed to the TableGroup which is asked to resolve it into a
ColumnBinding.
Christian what do you mean by "case where returning the union-query as
table would enable optimizations".
On Wed, Dec 21, 2016 at 7:42 AM Steve Ebersole wrote:
> I should have been more clear as to why this is a problem :)
>
> The columns are resolved as the persisters are built. Later as we
The general problem is actually a choice in the current EntityPersister
design, that we decided to leave for later in terms of whether to carry
that forward into the new persister design.
The original choice was to duplicate column and attribute info on an
EntityPersister from super and sub types.
I was thinking that during the SQL generation process or maybe an
earlier phase, one could analyze and determine that a column is only
used in a context that doesn't change the query result e.g. in a
predicate that can be removed. If by removing that predicate and thus
the column binding, there
