openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick (JIRA)" <>
Subject [jira] [Commented] (OPENJPA-152) Warn or throw an exception when a persistence unit has multiple named queries with the same name
Date Mon, 11 Jul 2011 21:39:59 GMT


Michael Dick commented on OPENJPA-152:

I'd be in favor of throwing an exception for the reason Dain mentioned above. It's very easy
to miss a warning like this one and not notice until you get back the wrong results. 

It would be interesting to run through the junit bucket with the change. The tests that use
SimpleEntity2 and SimpleEntity will break, but it'd be good to know how many other entities
have duplicate query names. 

If we do go forward with the change we'll want to make it configurable to give existing applications
a migration path. A new compatibility option is probably the way to go here.  

> Warn or throw an exception when a persistence unit has multiple named queries with the
same name
> ------------------------------------------------------------------------------------------------
>                 Key: OPENJPA-152
>                 URL:
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: jpa, logging, query
>            Reporter: Dain Sundstrom
>            Priority: Minor
> The JPA spec makes it quite easy for uses to create multiple named queries with the same
name.  The problem stems from named queries being declared as part of an entity either via
annotations or nested xml, but the name space for these queries is not scoped to the entity
but scoped to the whole persistence unit.  This problem is compounded due to the ease at which
the persistence unit is easily expanded with orm.xml files and with annotated beans.
> I propose that we throw a deployment exception when the combined entity mapping xml files
and listed classes contain multiple named queries with the same name.   If after deployment,
we discover another annotate bean that creates a conflict, we should log a ERROR and take
extra cautions to not override the existing in place query with the newly discovered one,
as this could drastically change the behavior of an application at runtime.
> Alternatively, we could just log warnings, but I would prefer a deployment exception
as it guarantees I'm not running with a randomly selected set or queries.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message