[hibernate-dev] SQM - PoC design doc

Steve Ebersole steve at hibernate.org
Wed Dec 21 09:53:54 EST 2016


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


More information about the hibernate-dev mailing list