[hibernate-dev] Treat support

Christian Beikov christian.beikov at gmail.com
Wed Aug 3 22:39:11 EDT 2016


I am sorry if this was already discussed somewhere but I couldn't find 
anything on the internet about this.

I am currently working on some testcases for the treat 
operator(https://github.com/beikov/jpa-treat-variations) that are 
apparently missing in the TCK as most JPA providers fail them. I'd like 
to offer them to you to be integrated into the hibernate testsuite.

Could you maybe run that locally and comment on the test cases? I am not 
100% sure that my understanding of what treat should do is right, but I 
tried to explain the reasoning for the expected test results inline.

The following points I found out during my testing.

  * Missing support for treated paths like "TREAT(...).property" in the
    parser. This is more or less workaroundable for non-root path
    treats. Since root paths can't be treat joined to my knowledge, some
    treated paths simple can't be used. Maybe in 90% of the cases
    hibernate will just resolve to the right property without needing
    the treat?
  * Missing support for a special case of treat join which apparently
    was overseen by the JPA spec which would be "TREAT(TREAT(rootPath AS
    Subtype).relation AS RelationSubtype)". Eclipselink not only allows
    this syntax but for inner joins also implements the appropriate
    logic. I am thinking that this might even work in hibernate without
    the inner treat, but would fail for attributes with same names.
  * Joins for supertypes and conditions on discriminators are not aware
    of the join type actually used in the treated join => left join
    should cascade up the type hierarchy and discriminator checks should
    contain OR DTYPE IS NULL for left join semantics. If treats are in
    subconditions the DTYPE checks might even be wrong
  * Joins are generated for the whole hierarchy not only the types that
    are treated => this might seem to be "just" a performance problem,
    but IMO actually is a correctness problem as it makes a difference
    if you get e.g. 2 rows or 2 * TYPES rows especially for count queries.

What I would like to know is if these bugs are planned to be tackled in 
Hibernate 6+ only or if they are considered for 4.3, 5.0, 5.1, 5.2 too.
Are these things too hard to fix without SQM or do capable people just 
lack time or interest to implement this?


Mit freundlichen Grüßen,
*Christian Beikov*

More information about the hibernate-dev mailing list