[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jpa-dev] Path navigation join semantics
|
Hi,
i guess the main reason is performance. Left joins are slower than inner
joins. And if your query is more complicated, left joins are much
slower. I have made a performance test query in our application's
database with 6 tables. One time with inner joins and one time with left
joins. The "left join everything"-query is 3,66 times slower. If you
change the default behavior from inner join semantics to left join
semantics then you will have to rewrite many of your jpql queries to get
the old performance back. And i see already hundreds of salty blog posts
before me how bad JakartaEE 10 is because it is sooo slow and bloaty.
Changing the default behavior would be OK in my eyes with a switch like
a query hint or a new option in the persistence.xml-file.
Cheers
Am 17.12.2020 um 13:17 schrieb Christian Beikov:
Hello,
I would like to discuss 4.4.4. Path Expressions, specifically this
section:
> Path expression navigability is composed using “inner join”
semantics. That is, if the value of a nonterminal field in the path
expression is null, the path is considered to have no value, and does
not participate in the determination of the result.
What is the reason behind requiring "inner join" semantics? From the
examples I have seen so far in the specification, they would also work
if a JPA provider would use "left join" semantics because all examples
use such paths in the WHERE clause and since NULL OP ANYTHING is
always UNKNOWN in SQL, the effects on cardinality are mostly the same
with "left join" semantics when used in a predicate context i.e. the
WHERE, HAVING or ON clauses or CASE predicate etc.
I'm asking this because it IMO makes not much sense to require "inner
join" semantics, especially for the SELECT, ORDER BY and GROUP BY
clauses but also in predicate context for null aware
predicates/functions.
I would like to be able to use the implicit navigation like this:
SELECT NEW my.company.MyDto(e.id, e.name, e.parent.name) FROM Entity e
but due to the current semantics this will currently filter out
entities that have no parent due to "inner join" semantics, so I have
to write the following instead:
SELECT NEW my.company.MyDto(e.id, e.name, p.name) FROM Entity e LEFT
JOIN e.parent p
I would like to propose changing the specification to require left
join semantics there and also for `Path.get` as specified in 6.5.5.
for JPA Criteria API. This will simplify a lot of queries and aligns
with what entity graphs do semantically.
Ideas? Comments?
Regards,
Christian
_______________________________________________
jpa-dev mailing list
jpa-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jpa-dev
