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 <st...@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.bei...@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" <st...@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 <st...@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@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
