[hibernate-dev] SQM - PoC design doc

[Christian Beikov]

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