Skip to main content

[jsr338-experts] Re: Ambiguities in exceptions for EntityManager.createQuery(…)

  • From: Linda DeMichiel <linda.demichiel@...>
  • To: jsr338-experts@...
  • Cc: Oliver Gierke <ogierke@...>, "thomas.hackel@..." <thomas.hackel@...>
  • Subject: [jsr338-experts] Re: Ambiguities in exceptions for EntityManager.createQuery(…)
  • Date: Tue, 17 Jul 2012 14:14:32 -0700
  • Organization: Oracle Corporation



On 7/17/2012 2:05 AM, Oliver Gierke wrote:
Hi all,

there are multiple (contradicting) sections in the spec defining the error 
cases of EntityManager.createQuery(…). The JavaDoc in 3.1.1 states:

/**
  * …
  * @throws IllegalArgumentException if the query string is
  *   found to be invalid
  */
public Query createQuery(String qlString);

Below the code sample we find the following section:

If the argument to the createQuery method is not a valid Java Persistence 
query string or a valid CriteriaQuery object, the IllegalArgumentException 
may be thrown or the query execution will fail and a PersistenceException 
will be thrown.

What does "may be thrown" exactly mean? Why is query execution discussed in 
this context? Does that mean that createQuery(…) might return a Query object that will 
only fail eventually when being executed?

Yes.  The provider may defer this check until the point where the query is to 
be executed.

If so, why is this allowed actually? If so how can one reliably check a query 
string for syntactical correctness?

I currently have code that tries to validate a query string by calling 
em.createQuery(…) and catching IllegalArgumentException as defined in the 
JavaDoc. Unfortunately I've just discovered Hibernate (3.x and 4.x) throwing 
IllegalStateException in case the query tree seems valid in general but fails 
being parsed later on.

em.createQuery("somethingAbsurd") ->  IllegalArgumentException
em.createQuery("select disinct(u) from User u") ->  IllegalStateException

I'd like to get a clear picture on what is actually required before filing a 
ticket against Hibernate. Is it worth to straighten that out in the upcoming 
version of the spec?


This point was discussed back in the JPA 1.0 days when this decision was made.

I'd like to hear the points of view of the JPA implementations represented 
here as to whether
it would be desirable to strengthen the requirements here or not.  For 
example, we could
consider adding a query property to indicate that the query string should be 
validated early.

-LInda


Cheers,
Ollie



[jsr338-experts] Ambiguities in exceptions for EntityManager.createQuery(…)

Oliver Gierke 07/17/2012

[jsr338-experts] Re: Ambiguities in exceptions for EntityManager.createQuery(…)

Linda DeMichiel 07/17/2012

[jsr338-experts] Re: Ambiguities in exceptions for EntityManager.createQuery(…)

Pinaki Poddar 07/18/2012

[jsr338-experts] Re: Ambiguities in exceptions for EntityManager.createQuery(…)

Oliver Gierke 07/18/2012

[jsr338-experts] Re: Ambiguities in exceptions for EntityManager.createQuery(…)

Pinaki Poddar 07/18/2012

[jsr338-experts] Re: Ambiguities in exceptions for EntityManager.createQuery(…)

Oliver Gierke 07/19/2012
 
 
Close
loading
Please Confirm
Close