[hibernate-dev] SQM - PoC design doc

[Steve Ebersole]

The general problem is actually a choice in the current EntityPersister
design, that we decided to leave for later in terms of whether to carry
that forward into the new persister design.

The original choice was to duplicate column and attribute info on an
EntityPersister from super and sub types.  E.g. given a hierarchy like
Human <- Employee <- Manager:

   - Human contains the column and attribute info from Employee and
   Manager.
   - Employee contains the column and attribute info from Human and Manager
   - Manager contains the column and attribute info from Employee and Human

I have a semi-working solution accounting for the columns part.  But the
attributes part is still tbd.  I personally would rather see declared
attributes only on the persister defining them and persisters with links to
their super/subs to access attributes when needed.


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