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 :)

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&gt; 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&gt; 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 https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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&gt; 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&gt; 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 > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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