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
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.
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
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.
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 think it should return the Columns
that reports the physical Table for its Table.
On 20 Dec 2016 22:02, "Steve Ebersole" wrote:
Christian provided some good feedback on the HipChat channel and we have
started a discussion about those there.
I have run into a new one specific to union-subclass
Christian provided some good feedback on the HipChat channel and we have
started a discussion about those there.
I have run into a new one specific to union-subclasses and building the
Table/Column structures for these. The problem is that we need 2
distinction understandings of the Tables for th
I have pushed a newly updated version of the design.adoc bringing the
discussions up-to-date with the latest code/design.
This PoC work is getting very far along and I really have not had much
feedback. My concern is that this code is only going to become harder to
review (more to look at) as more
