[hibernate-dev] SQM - PoC design doc

[Christian Beikov]

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