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