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