Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Conditional LEFT JOIN in JPQL

Hi Bernard,

I suspect that a JPQL update would require a fairly big JPQL grammar change. We are hesitant to make big changes to our JPQL implementation because the likelihood of maintaining backward compatibility when the next JPA specification comes out is low since although we contribute the the spec, we are only one of the groups that is involved and inevitably there will be some changes in what we have come up with. Additionally, large changes are at a risk of affecting our TCK compatility.

For issues like this, we tend to try to address them with EclipseLink native API and wait for spec-direction before changing our JPQL parser. If you are interested in using EclipseLink-native API we can work through an example and see if we can produce what you are looking for with the current code, or if there are some enhancement requests that need to be filed.

Let me know,

bht@xxxxxxxxxxxxx wrote:

Since I asked you for support to approach the spec group I ow you a
big Thank You for your initiative. It has been a pleasure to see this
unfold to its current stage.

I am offering to provide a standalone testcase that works with a
genuine JPA query that returns a DTO list, using a left join without
the sub-condition.

You would then be able to experiment with the testcase, effectively
trying to plug in the sub-condition into the join.

Ideally, the result would still be the same DTO list format, except
the number of rows would be different. The aim of all this is to get a
really good picture of the result that the JPA enhancement should
finally produce. The enhanced JPA could then replace your plug-in
solution seamlessly.

How does this sound to you?



On Thu, 06 May 2010 15:58:32 -0400, you wrote:

Hi Vidas,

  Thanks for the lesson.

With your help and Bernards', I have managed to get this feature on an initial list for consideration for the next JPA specification. The spec is still in the very early stages, and I do not have any idea where it fits in terms of priority compared to the other items being considered.

If you are interested in an EclispeLink-native-api solution, I can do some experimentation to see what EclipseLink can provide. The basic idea is we would define something called a OneToOneQueryKey using the fields you want to join ON and then query across that query key.

Let me know if this kind of solution is of interest to you,

Vidas wrote:
Hi, Tom,

2010/5/5 Tom Ware <tom.ware@xxxxxxxxxx <mailto:tom.ware@xxxxxxxxxx>>

    I appologize for my lack of understanding but...

    How will the results of the following queries be different (assuming
    a mapped relationship between dealer and vehicle using v.dealer_id =
    d.dealer_id  as the foreign key relationship)?

    1. SELECT <>, count( <>) FROM
    dealer d LEFT OUTER JOIN vehicle v ON
    (v.dealer_id = d.dealer_id AND v.type = 'New') GROUP BY

    2. SELECT <>, count( <>) FROM
    dealer d LEFT OUTER JOIN d.vehicles v where v.type = 'New' or v.type
    isnull GROUP BY <>

Second query will be missing dealers, who only have old vehicles.

Taking other Bernards example:

1. SELECT <>, <> FROM product p LEFT OUTER JOIN product_favorite f
ON ( <> = f.product_id AND f.user_id = :userId)

2. SELECT <>, <> FROM product p LEFT OUTER JOIN p.product_favorite f
WHERE f.user_id = :userId OR f.user_id isnull

Second query will be missing products, which are favorites only to other users.

And my case:

SELECT <>, e1.fieldValue AS language, e2.fieldValue AS nationality
  FROM Country c
LEFT JOIN ExtCharFields e1 ON <>=e1.country_id AND e1.fieldName = "language" LEFT JOIN ExtCharFields e2 ON <>=e2.country_id AND e2.fieldName = "nationality"

It isn't possible to write JPQL query at all



eclipselink-users mailing list
eclipselink-users mailing list

eclipselink-users mailing list

Back to the top