[
https://issues.apache.org/jira/browse/OPENJPA-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062150#comment-13062150
]
Jacob Nowosatka commented on OPENJPA-152:
-----------------------------------------
OpenJPA does handle multiple queries with the same name by ignoring the
duplicate queries and logging a warning message.
6734 test WARN [main] openjpa.MetaData - Ignoring duplicate query "FindOne" in
"class org.apache.openjpa.persistence.query.SimpleEntity2". A query with the
same name been already declared in "class
org.apache.openjpa.persistence.query.SimpleEntity".
An exception could be thrown, or this could be left as is.
> Warn or throw an exception when a persistence unit has multiple named queries
> with the same name
> ------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-152
> URL: https://issues.apache.org/jira/browse/OPENJPA-152
> 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: http://www.atlassian.com/software/jira