Skip to main content

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

  • From: Oliver Gierke <ogierke@...>
  • To: "jsr338-experts@..." <jsr338-experts@...>
  • Subject: [jsr338-experts] Re: Ambiguities in exceptions for EntityManager.createQuery(…)
  • Date: Wed, 18 Jul 2012 02:20:53 -0700
  • Accept-language: de-DE, en-US
  • Acceptlanguage: de-DE, en-US

I just did a brief check against OpenJpa 2.2.0. It's currently rejecting both 
createQuery(String foo) and createNamedQuery(String name) if the query is 
invalid or the named query with the name does not even exist.

What benefits does artificially delaying query validation have? It's the 
opposite of the fail fast principle. Right now you'd actually be the odd one 
out if you returned a Query object not being executable which severely 
impacts portability of applications and thus subverts the purpose of having 
an API like this in the first place. How shall a client actually deal with 
the information that the method could throw an exception but may be not?

In every case I think the JavaDoc needs to be updated in case we really 
decide to go for that option (which I'd like to vote against and which is 
currently no one using and I don't see any benefit) as it's highly misleading 
currently.

Cheers,
Ollie

Am 18.07.2012 um 04:14 schrieb Pinaki Poddar:

> Hi,
> > 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.
> 
> The current spec allows certain flexibility for the implementations to 
> parse a query during execution as opposed to construction. In OpenJPA, we 
> prefer such flexibility. 
> 
> Regards --
> 
> Pinaki Poddar                          
> Chair, Apache OpenJPA Project           http://openjpa.apache.org/
> JPA Expert Group Member
> Application & Integration Middleware
> 
> 
> 
> 
> 
> 
> <graycol.gif>Linda DeMichiel ---07/17/2012 02:15:29 PM---On 7/17/2012 2:05 
> AM, Oliver Gierke wrote: > Hi all,
> 
> From: Linda DeMichiel <linda.demichiel@...>
> To:   jsr338-experts@...
> Cc:   Oliver Gierke <ogierke@...>, "thomas.hackel@..." <thomas.hackel@...>
> Date: 07/17/2012 02:15 PM
> Subject:      [jsr338-experts] Re: Ambiguities in exceptions for 
> EntityManager.createQuery(…)
> 
> 
> 
> 
> 
> 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
> >
> 
> 

-- 
/**
 * @author Oliver Gierke - Senior Member Technical Staff
 *
 * @param email ogierke@...
 * @param phone +49-351-30929001
 * @param fax   +49-351-418898439
 * @param skype einsdreizehn
 * @see http://www.olivergierke.de
 */



[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