[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jpa-dev] Path navigation join semantics
|
Just because the default is left join, doesn't mean a provider may not
issue an inner join if applicable. If an association is optional =
false, an inner join could be rendered. A JPA provider could also check
if an attribute is used in top level null-rejecting predicates and then
also issue an inner join for such cases, so I guess if these
optimizations are implemented, existing queries won't will still issue
inner joins in most cases.
Do you have some kind of benchmark that I can use to reproduce the
results you are seeing? It would really surprise me if left joins really
are that much slower on the major DBs. Which DB are you using? Also,
what does 3,66 time slower mean? Are we talking milliseconds, microseconds?
What kind of blog posts are you talking about? Jakarta EE 10 is still in
development, so how can there be blog posts about it being slow or
bloaty? I mostly use Wildfly which is Jakarta EE 8/9 compatible and it
works fine for me. I don't know what other people are doing or what kind
of application servers they are referring to, but haters gonna hate.
Regards,
Christian
Am 18.12.2020 um 10:16 schrieb Aleksander Nowak:
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
_______________________________________________
jpa-dev mailing list
jpa-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jpa-dev