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 are no column bindings left for a table, the
table could be omitted. By having the physical table being returned by
the column, I was thinking it might get easier to implement this.
I was thinking about whether using the union-query as the "table" for a
column would allow for optimizations, but couldn't come up with ideas
yet. Hope that makes things clearer?
Am 21.12.2016 um 15:53 schrieb Steve Ebersole:
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 <steve(a)hibernate.org
<mailto:steve@hibernate.org>> 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
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. To do that in
needs to find the TableBinding within the TableGroup for that
Colum#sourceTable.
A ColumnBinding is a reference to a column in relation to a
specific table reference. In other words a qualified column
reference.
It is conceivable that some special Table definition could help.
In fact that is the preliminary path I started down by creating a
UnionSubclassTable specialization. So far that is still hitting
some problems.
On Wed, Dec 21, 2016, 2:36 AM Christian Beikov
<christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>>
wrote:
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 furthermore the table references themselves which have by
proof no
effect on the query outcome.
How about letting a "Table" have a kind of parent table? The
physical
table could then have the union-query as parent table.
Have you thought about possible implications of the approaches
apart
from having to create "duplicate" column objects?
Am 21.12.2016 um 07:28 schrieb andrea boriero:
> I think it should return the Columns
> that reports the physical Table for its Table.
>
> On 20 Dec 2016 22:02, "Steve Ebersole" <steve(a)hibernate.org
<mailto:steve@hibernate.org>> 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-subclasses and
building the
> Table/Column structures for these. The problem is that we
need 2
> distinction understandings of the Tables for these entities:
> 1) Is the union query used for selects.
> 2) is the physical hierarchy tables for DML operations
>
> The problem comes from the fact that Column holds a link to
its Table.
> Here we'd have to create duplicated columns, one for the
union-query table
> and one for the physical tables. And then we'd have to do
the same for
> things that expose columns. For example, if I ask the
"identifier
> descriptor" for a union-subclass entity for its columns, do
I get the
> Columns that report the union-query as its Table? Or do I
get the Columns
> that report the physical Table for its Table?
>
>
> On Fri, Dec 16, 2016 at 10:15 PM Steve Ebersole
<steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote:
>
>> 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 time passes.
>>
>> I know digging in the code (it is a lot) is not really
feasible, but
>> please at least take some time to look over the design.adoc
in the poc
>> repo.
>>
>> Feedback sooner is better :)
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev