Code organization

[Daryl Stultz]

Hello,

I'm frustrated by the fact that I need to define @NamedQuery and others
inside my entity classes. I would like to put what I consider "logic" where
I think it's appropriate which is often not with the model. Is there a way
to programmatically define Named Queries Sql Result Set Mappings, etc and
register them with the persistence engine? I.e. is there any alternative to
using annotations/xml for defining these things?

String query = "select o...";
NamedQuery nq = new NamedQuery(query);
Persistence.registerNamedQuery(nq);

Thanks.

--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:[hidden email]

[Pinaki Poddar]

Hi Daryl,
 This is one feature, for a long time, I am interested to be included in JPA or at least in OpenJPA. Having your queries *only* in the major compilation unit is a poor idea for usability point of view and takes away much of the power from tuning a query a posteriori.
  However, I had considered the facility slightly differently than yours. The primary feature that I considered important in this aspect is to dissociate my queries from the major compilation units. The compilation units will only refer them by name.

 How about the following
  <property name="openjpa.NamedQueryRegistry" value="path/to/file/that/contains/NamedQueries.java"/>

  and in code
   Query q = em.createQuery("ANameThatAppearsInNamedQueryRegsitry");

Daryl Stultz wrote:

Hello,

I'm frustrated by the fact that I need to define @NamedQuery and others
inside my entity classes. I would like to put what I consider "logic" where
I think it's appropriate which is often not with the model. Is there a way
to programmatically define Named Queries Sql Result Set Mappings, etc and
register them with the persistence engine? I.e. is there any alternative to
using annotations/xml for defining these things?

String query = "select o...";
NamedQuery nq = new NamedQuery(query);
Persistence.registerNamedQuery(nq);

Thanks.

--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:[e-mail]

[Daryl Stultz]

On Fri, Jun 5, 2009 at 11:33 AM, Pinaki Poddar <[hidden email]> wrote:

>
>
>  However, I had considered the facility slightly differently than yours.


Naturally, since you're a JPA expert and I'm just a lowly beginner... I was
just putting out a "sketch" to help folks understand what I was after.

>
> The primary feature that I considered important in this aspect is to
> dissociate my queries from the major compilation units.


By "major compilation units" do you mean "classes mostly of Java (and not
embedded SQL/JPQL)"?

>
>  How about the following
>  <property name="openjpa.NamedQueryRegistry"
> value="path/to/file/that/contains/NamedQueries.java"/>
>
>  and in code
>   Query q = em.createQuery("ANameThatAppearsInNamedQueryRegsitry");
>
> Not bad, so far. I imagine NamedQueries.java would implement some interface
that expects a return of a collection of NamedQueries or something?

--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:[hidden email]

[DWoods]

Pinaki Poddar wrote:

> Hi Daryl,
>  This is one feature, for a long time, I am interested to be included in JPA
> or at least in OpenJPA. Having your queries *only* in the major compilation
> unit is a poor idea for usability point of view and takes away much of the
> power from tuning a query a posteriori.
>   However, I had considered the facility slightly differently than yours.
> The primary feature that I considered important in this aspect is to
> dissociate my queries from the major compilation units. The compilation
> units will only refer them by name.
>
>  How about the following
>   <property name="openjpa.NamedQueryRegistry"
> value="path/to/file/that/contains/NamedQueries.java"/>
>
>   and in code
>    Query q = em.createQuery("ANameThatAppearsInNamedQueryRegsitry");
>

Maybe by using spring/osgi blueprint to inject the config?
Having to supply Java classes seems limiting, if the true objective is
dynamic config to support agile development or varying Dev/QA
environments....

>
> Daryl Stultz wrote:
>> Hello,
>>
>> I'm frustrated by the fact that I need to define @NamedQuery and others
>> inside my entity classes. I would like to put what I consider "logic"
>> where
>> I think it's appropriate which is often not with the model. Is there a way
>> to programmatically define Named Queries Sql Result Set Mappings, etc and
>> register them with the persistence engine? I.e. is there any alternative
>> to
>> using annotations/xml for defining these things?
>>
>> String query = "select o...";
>> NamedQuery nq = new NamedQuery(query);
>> Persistence.registerNamedQuery(nq);
>>
>> Thanks.
>>
>> --
>> Daryl Stultz
>> _____________________________________
>> 6 Degrees Software and Consulting, Inc.
>> http://www.6degrees.com
>> mailto:[hidden email]
>>
>>
>
>
> -----
> Pinaki Poddar                      http://ppoddar.blogspot.com/
>                                      
> http://www.linkedin.com/in/pinakipoddar
> OpenJPA PMC Member/Committer
> JPA Expert Group Member

[Michael Dick]

Alternatively you could just include a MappedSuperclass that holds the query
annotations in your persistence context. No need for a property, but you
have to make sure the MappedSuperclass is part of the PersistenceUnit (add
to classes in persistence.xml, specify via
openjpa.MetaDataFactory=jpa(Types=${mappedSuperClas.class};{other types go
here}), or make sure exclude-unlisted-classes==false).

Kind of kludgy but the real key (at least for OpenJPA) is to make sure the
MetaData of the class containing @NamedQuery is parsed.

Maybe I'm misunderstanding the use case, but the real coupling is the named
queries to persistence.xml (persistence unit) - not necessarily the
compilable unit. One may have a set of entities in a utility jar which is
then used by an EJB module. The EJB module could contain persistence.xml and
orm.xml (put your query definitions here) or the MappedSuperclass I
mentioned above. That would put the query logic closer to the app or at
least outside of the model.

The same approach could be done for JSE / Servlets / whatever.

Hope this helps,

-mike

On Fri, Jun 5, 2009 at 1:54 PM, Donald Woods <[hidden email]> wrote:

>
>
> Pinaki Poddar wrote:
>
>> Hi Daryl,
>>  This is one feature, for a long time, I am interested to be included in
>> JPA
>> or at least in OpenJPA. Having your queries *only* in the major
>> compilation
>> unit is a poor idea for usability point of view and takes away much of the
>> power from tuning a query a posteriori.
>>  However, I had considered the facility slightly differently than yours.
>> The primary feature that I considered important in this aspect is to
>> dissociate my queries from the major compilation units. The compilation
>> units will only refer them by name.
>>  How about the following
>>  <property name="openjpa.NamedQueryRegistry"
>> value="path/to/file/that/contains/NamedQueries.java"/>
>>
>>  and in code
>>   Query q = em.createQuery("ANameThatAppearsInNamedQueryRegsitry");
>>
>>
> Maybe by using spring/osgi blueprint to inject the config?
> Having to supply Java classes seems limiting, if the true objective is
> dynamic config to support agile development or varying Dev/QA
> environments....
>
>
>
>
>> Daryl Stultz wrote:
>>
>>> Hello,
>>>
>>> I'm frustrated by the fact that I need to define @NamedQuery and others
>>> inside my entity classes. I would like to put what I consider "logic"
>>> where
>>> I think it's appropriate which is often not with the model. Is there a
>>> way
>>> to programmatically define Named Queries Sql Result Set Mappings, etc and
>>> register them with the persistence engine? I.e. is there any alternative
>>> to
>>> using annotations/xml for defining these things?
>>>
>>> String query = "select o...";
>>> NamedQuery nq = new NamedQuery(query);
>>> Persistence.registerNamedQuery(nq);
>>>
>>> Thanks.
>>>
>>> --
>>> Daryl Stultz
>>> _____________________________________
>>> 6 Degrees Software and Consulting, Inc.
>>> http://www.6degrees.com
>>> mailto:[hidden email]
>>>
>>>
>>>
>>
>> -----
>> Pinaki Poddar                      http://ppoddar.blogspot.com/
>>
>> http://www.linkedin.com/in/pinakipoddar
>> OpenJPA PMC Member/Committer
>> JPA Expert Group Member
>>
>

[Daryl Stultz]

On Fri, Jun 5, 2009 at 3:51 PM, Michael Dick <[hidden email]>wrote:

> Maybe I'm misunderstanding the use case, but the real coupling is the named
> queries to persistence.xml (persistence unit) - not necessarily the
> compilable unit.


This is the case for me. In my pre-JPA world I have a Widget model class and
a WidgetUtils class which manipulates Widgets, call WidgetUtils "business
logic". I might define WidgetUtils.sharpenDullWidgets() and in that method I
have

String query "select * from Widgets where Widgets.dull = 1";
... get connection, run query, traverse resultset...

I don't like embedding SQL in my Java, but I do like have the business logic
contained in the query right in the business method sharpenDullWidgets. So
really, my proposal doesn't get me what I want. Putting named queries in a
super class, a registry class or an xml file helps in that it gets the
queries out of the model but it doesn't put it in the business logic class.

Really, I think the best I could hope for is to be able to define named
queries as annotations of the method that uses it even if the method is in a
non-entity class:

public class WidgetUtils {

@NamedQueries( {
    @NamedQuery(name="findDullWidgets",
        query="select...")
})
public static void sharpenDullWidgets() {
     Query query = em.createNamedQuery("findDullWidgets");
}

The query is much closer to the point of usage. I don't think anybody would
be interested in making the above work. Of course I could write the query on
the spot and the only thing I lose is the performance of the pre-compiled
query.

--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:[hidden email]

[David Beer-2]

Hi All

I too would much rather see @NamedQuery(ies) defined in a seperate
class like I do other more complicated queries. I also see this as a
good way of keeping things modular or decoupled from the model.

Using a seperate java class which then registers those queries at run
time would be a good way of doing things. The registration not need be
in the persistence.xml file as long as it can be added to the
persistence unit later.

David

On Fri, 5 Jun 2009 08:33:19 -0700 (PDT)
Pinaki Poddar <[hidden email]> wrote:

>
> Hi Daryl,
>  This is one feature, for a long time, I am interested to be included
> in JPA or at least in OpenJPA. Having your queries *only* in the
> major compilation unit is a poor idea for usability point of view and
> takes away much of the power from tuning a query a posteriori.
>   However, I had considered the facility slightly differently than
> yours. The primary feature that I considered important in this aspect
> is to dissociate my queries from the major compilation units. The
> compilation units will only refer them by name.
>
>  How about the following
>   <property name="openjpa.NamedQueryRegistry"
> value="path/to/file/that/contains/NamedQueries.java"/>
>
>   and in code
>    Query q = em.createQuery("ANameThatAppearsInNamedQueryRegsitry");
>
>
> Daryl Stultz wrote:
> >
> > Hello,
> >
> > I'm frustrated by the fact that I need to define @NamedQuery and
> > others inside my entity classes. I would like to put what I
> > consider "logic" where
> > I think it's appropriate which is often not with the model. Is
> > there a way to programmatically define Named Queries Sql Result Set
> > Mappings, etc and register them with the persistence engine? I.e.
> > is there any alternative to
> > using annotations/xml for defining these things?
> >
> > String query = "select o...";
> > NamedQuery nq = new NamedQuery(query);
> > Persistence.registerNamedQuery(nq);
> >
> > Thanks.
> >
> > --
> > Daryl Stultz
> > _____________________________________
> > 6 Degrees Software and Consulting, Inc.
> > http://www.6degrees.com
> > mailto:[hidden email]
> >
> >
>
>
> -----
> Pinaki Poddar                      http://ppoddar.blogspot.com/
>                                      
> http://www.linkedin.com/in/pinakipoddar
> OpenJPA PMC Member/Committer
> JPA Expert Group Member

[Michael Dick]

On Fri, Jun 5, 2009 at 3:12 PM, Daryl Stultz <[hidden email]> wrote:

> On Fri, Jun 5, 2009 at 3:51 PM, Michael Dick <[hidden email]
> >wrote:
>
> > Maybe I'm misunderstanding the use case, but the real coupling is the
> named
> > queries to persistence.xml (persistence unit) - not necessarily the
> > compilable unit.
>
>
> This is the case for me. In my pre-JPA world I have a Widget model class
> and
> a WidgetUtils class which manipulates Widgets, call WidgetUtils "business
> logic". I might define WidgetUtils.sharpenDullWidgets() and in that method
> I
> have
>
> String query "select * from Widgets where Widgets.dull = 1";
> ... get connection, run query, traverse resultset...
>
> I don't like embedding SQL in my Java, but I do like have the business
> logic
> contained in the query right in the business method sharpenDullWidgets. So
> really, my proposal doesn't get me what I want. Putting named queries in a
> super class, a registry class or an xml file helps in that it gets the
> queries out of the model but it doesn't put it in the business logic class.
>
> Really, I think the best I could hope for is to be able to define named
> queries as annotations of the method that uses it even if the method is in
> a
> non-entity class:
>
> public class WidgetUtils {
>
> @NamedQueries( {
>    @NamedQuery(name="findDullWidgets",
>        query="select...")
> })
> public static void sharpenDullWidgets() {
>     Query query = em.createNamedQuery("findDullWidgets");
> }
>
> The query is much closer to the point of usage. I don't think anybody would
> be interested in making the above work. Of course I could write the query
> on
> the spot and the only thing I lose is the performance of the pre-compiled
> query.
>

I think the query isn't compiled until the first time you use it and then
it's cached by its string form. Might have to look at that code again to
verify though.

If that's the case then I think I'd just use a static string instead of a
NamedQuery.

public class WidgetUtils  {
    private static final String qFindDullWidgets = "select . . .";

    public static void sharpenDullWidgets() {
        Query query = em.createQuery(qFindDullWidgets);
    }
}

I don't think there's a significant performance difference between the two
(if the annotation worked). The annotations might be more expressive
though..

In order to make the annotations work automagically we (JPA provider) would
have to scan the classpath for non entity/msc types that have @NamedQuery
annotations.. If exclude-unlisted-classes == false this might not be much
additional overhead.

You're welcome to open a JIRA for this as an improvement if it'd be a big
help to you. I can't promise a target date though.

-mike


>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:[hidden email]
>

[Michael Dick]

On Fri, Jun 5, 2009 at 3:25 PM, David Beer <[hidden email]>wrote:

> Hi All
>
> I too would much rather see @NamedQuery(ies) defined in a seperate
> class like I do other more complicated queries. I also see this as a
> good way of keeping things modular or decoupled from the model.
>
> Using a seperate java class which then registers those queries at run
> time would be a good way of doing things. The registration not need be
> in the persistence.xml file as long as it can be added to the
> persistence unit later.

This can be done, provided the separate class is an Entity /
MappedSuperclass. You have to add it to the PersistenceUnit at factory
creation time though.

Something like this should work..

Map m = new HashMap()
m.put("openjpa.MetaDataFactory=jpa(Types=${list all your entity types
here};${new query container type goes here})");

emf = javax.persistence.Persistence.createEntityManagerFactory(emfName, m);

The catch is that if Types is specified it must be the complete list (as I
remember).

hth
-mike

>
> David
>
> On Fri, 5 Jun 2009 08:33:19 -0700 (PDT)
> Pinaki Poddar <[hidden email]> wrote:
>
> >
> > Hi Daryl,
> >  This is one feature, for a long time, I am interested to be included
> > in JPA or at least in OpenJPA. Having your queries *only* in the
> > major compilation unit is a poor idea for usability point of view and
> > takes away much of the power from tuning a query a posteriori.
> >   However, I had considered the facility slightly differently than
> > yours. The primary feature that I considered important in this aspect
> > is to dissociate my queries from the major compilation units. The
> > compilation units will only refer them by name.
> >
> >  How about the following
> >   <property name="openjpa.NamedQueryRegistry"
> > value="path/to/file/that/contains/NamedQueries.java"/>
> >
> >   and in code
> >    Query q = em.createQuery("ANameThatAppearsInNamedQueryRegsitry");
> >
> >
> > Daryl Stultz wrote:
> > >
> > > Hello,
> > >
> > > I'm frustrated by the fact that I need to define @NamedQuery and
> > > others inside my entity classes. I would like to put what I
> > > consider "logic" where
> > > I think it's appropriate which is often not with the model. Is
> > > there a way to programmatically define Named Queries Sql Result Set
> > > Mappings, etc and register them with the persistence engine? I.e.
> > > is there any alternative to
> > > using annotations/xml for defining these things?
> > >
> > > String query = "select o...";
> > > NamedQuery nq = new NamedQuery(query);
> > > Persistence.registerNamedQuery(nq);
> > >
> > > Thanks.
> > >
> > > --
> > > Daryl Stultz
> > > _____________________________________
> > > 6 Degrees Software and Consulting, Inc.
> > > http://www.6degrees.com
> > > mailto:[hidden email]
> > >
> > >
> >
> >
> > -----
> > Pinaki Poddar                      http://ppoddar.blogspot.com/
> >
> > http://www.linkedin.com/in/pinakipoddar
> > OpenJPA PMC Member/Committer
> > JPA Expert Group Member
>
>

[Pinaki Poddar]

Hi Daryl,
  Actually, there is an way you can externalize your queries from your Java code.
  orm.xml has a 'global' named-query clause.
  1. put you JPQL query string there.
  2. If you do not want to write your POJO entities in orm.xml, that is OK.
  3. specify orm.xml in <mapping-file> clause in persistence.xml

  So effectively we got 3 things:

  1. Employee.java
  @Entity // this is required if you did not include it in orm.xml
   public class Employee {...}

  2. a orm.xml only with your queries
   <?xml version="1.0" encoding="UTF-8"?>
   <entity-mappings>
     <named-query name="Employee.findAll">
       <query>SELECT x FROM Employee x</query>
     </named-query>
   </entity-mappings>

  3. persistence.xml that has both orm.xml and <class>
    <persistence-unit name="named-query">
        <mapping-file>orm.xml</mapping-file>
        <class>access.Employee</class>
    </persistence-unit>


  Now your code can refer to em.createNamedQuery("Employee.findAll");
and you can tune this queries post-compilation by merely editing orm.xml.

PS: > Naturally, since you're a JPA expert and I'm just a lowly beginner...
   In this game, anybody is as good as the other. That self-serving 'expert' designation is ego-massaging -- pure and simple.

Daryl Stultz wrote:

On Fri, Jun 5, 2009 at 11:33 AM, Pinaki Poddar <[e-mail]> wrote:

>
>
>  However, I had considered the facility slightly differently than yours.


Naturally, since you're a JPA expert and I'm just a lowly beginner... I was
just putting out a "sketch" to help folks understand what I was after.

>
> The primary feature that I considered important in this aspect is to
> dissociate my queries from the major compilation units.


By "major compilation units" do you mean "classes mostly of Java (and not
embedded SQL/JPQL)"?

>
>  How about the following
>  <property name="openjpa.NamedQueryRegistry"
> value="path/to/file/that/contains/NamedQueries.java"/>
>
>  and in code
>   Query q = em.createQuery("ANameThatAppearsInNamedQueryRegsitry");
>
> Not bad, so far. I imagine NamedQueries.java would implement some interface
that expects a return of a collection of NamedQueries or something?

--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:[e-mail]

[David Beer-2]

Hi Mike


This sort of method would certainly fit my needs and method of working
more. Is there a JIRA item for this so that I can add a comment?

On Fri, 5 Jun 2009 16:50:59 -0500 Michael Dick
<[hidden email]> wrote:

> On Fri, Jun 5, 2009 at 3:25 PM, David Beer
> <[hidden email]>wrote:
>
> > Hi All
> >
> > I too would much rather see @NamedQuery(ies) defined in a seperate
> > class like I do other more complicated queries. I also see this as a
> > good way of keeping things modular or decoupled from the model.
> >
> > Using a seperate java class which then registers those queries at
> > run time would be a good way of doing things. The registration not
> > need be in the persistence.xml file as long as it can be added to
> > the persistence unit later.
>
>
> This can be done, provided the separate class is an Entity /
> MappedSuperclass. You have to add it to the PersistenceUnit at factory
> creation time though.
>
> Something like this should work..
>
> Map m = new HashMap()
> m.put("openjpa.MetaDataFactory=jpa(Types=${list all your entity types
> here};${new query container type goes here})");
>
> emf =
> javax.persistence.Persistence.createEntityManagerFactory(emfName, m);
>
> The catch is that if Types is specified it must be the complete list
> (as I remember).
>
> hth
> -mike
>
>
>
> >
> > David
> >
> > On Fri, 5 Jun 2009 08:33:19 -0700 (PDT)
> > Pinaki Poddar <[hidden email]> wrote:
> >
> > >
> > > Hi Daryl,
> > >  This is one feature, for a long time, I am interested to be
> > > included in JPA or at least in OpenJPA. Having your queries
> > > *only* in the major compilation unit is a poor idea for usability
> > > point of view and takes away much of the power from tuning a
> > > query a posteriori. However, I had considered the facility
> > > slightly differently than yours. The primary feature that I
> > > considered important in this aspect is to dissociate my queries
> > > from the major compilation units. The compilation units will only
> > > refer them by name.
> > >
> > >  How about the following
> > >   <property name="openjpa.NamedQueryRegistry"
> > > value="path/to/file/that/contains/NamedQueries.java"/>
> > >
> > >   and in code
> > >    Query q =
> > > em.createQuery("ANameThatAppearsInNamedQueryRegsitry");
> > >
> > >
> > > Daryl Stultz wrote:
> > > >
> > > > Hello,
> > > >
> > > > I'm frustrated by the fact that I need to define @NamedQuery and
> > > > others inside my entity classes. I would like to put what I
> > > > consider "logic" where
> > > > I think it's appropriate which is often not with the model. Is
> > > > there a way to programmatically define Named Queries Sql Result
> > > > Set Mappings, etc and register them with the persistence
> > > > engine? I.e. is there any alternative to
> > > > using annotations/xml for defining these things?
> > > >
> > > > String query = "select o...";
> > > > NamedQuery nq = new NamedQuery(query);
> > > > Persistence.registerNamedQuery(nq);
> > > >
> > > > Thanks.
> > > >
> > > > --
> > > > Daryl Stultz
> > > > _____________________________________
> > > > 6 Degrees Software and Consulting, Inc.
> > > > http://www.6degrees.com
> > > > mailto:[hidden email]
> > > >
> > > >
> > >
> > >
> > > -----
> > > Pinaki Poddar                      http://ppoddar.blogspot.com/
> > >
> > > http://www.linkedin.com/in/pinakipoddar
> > > OpenJPA PMC Member/Committer
> > > JPA Expert Group Member
> >
> >

[Daryl Stultz]

On Fri, Jun 5, 2009 at 5:54 PM, Pinaki Poddar <[hidden email]> wrote:

>
> Hi Daryl,
>  Actually, there is an way you can externalize your queries from your Java
> code.


Thanks Pinaki, I might be satisfied with that.

--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:[hidden email]

[Daryl Stultz]

On Fri, Jun 5, 2009 at 5:47 PM, Michael Dick <[hidden email]>wrote:

> I think the query isn't compiled until the first time you use it and then
> it's cached by its string form. Might have to look at that code again to
> verify though.

...

> I don't think there's a significant performance difference between the two
> (if the annotation worked). The annotations might be more expressive
> though..


I'm a bit confused. Are named queries a feature that exists solely for the
purpose of reuse or is there a performance advantage?

--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:[hidden email]

[Michael Dick]

On Mon, Jun 8, 2009 at 9:36 AM, Daryl Stultz <[hidden email]> wrote:

> On Fri, Jun 5, 2009 at 5:47 PM, Michael Dick <[hidden email]
> >wrote:
>
> > I think the query isn't compiled until the first time you use it and then
> > it's cached by its string form. Might have to look at that code again to
> > verify though.
>
> ...
>
> > I don't think there's a significant performance difference between the
> two
> > (if the annotation worked). The annotations might be more expressive
> > though..
>
>
> I'm a bit confused. Are named queries a feature that exists solely for the
> purpose of reuse or is there a performance advantage?
>

There's no performance advantage to @NamedQueries.  NamedQueries will
perform identical to a static JPQL string - first time it's used we'll
compile and cache the generated SQL, optionally cache the results, etc. The
documentation on the query SQL cache [1] might be of interest though.

[1]
http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_cache_querysql

NamedQueries are more readable than a static JPQL string but you shouldn't
choose them to improve performance.

Regards,

-mike




>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:[hidden email]
>

[Michael Dick]

Hi David,

Actually this is working today - I wrote a simple testcase to verify it on trunk. Should work on 1.2.x as well.

-mike

David Beer-2 wrote:

Hi Mike


This sort of method would certainly fit my needs and method of working
more. Is there a JIRA item for this so that I can add a comment?

On Fri, 5 Jun 2009 16:50:59 -0500 Michael Dick
<[e-mail]> wrote:

> On Fri, Jun 5, 2009 at 3:25 PM, David Beer
> <[e-mail]>wrote:
>
> > Hi All
> >
> > I too would much rather see @NamedQuery(ies) defined in a seperate
> > class like I do other more complicated queries. I also see this as a
> > good way of keeping things modular or decoupled from the model.
> >
> > Using a seperate java class which then registers those queries at
> > run time would be a good way of doing things. The registration not
> > need be in the persistence.xml file as long as it can be added to
> > the persistence unit later.
>
>
> This can be done, provided the separate class is an Entity /
> MappedSuperclass. You have to add it to the PersistenceUnit at factory
> creation time though.
>
> Something like this should work..
>
> Map m = new HashMap()
> m.put("openjpa.MetaDataFactory=jpa(Types=${list all your entity types
> here};${new query container type goes here})");
>
> emf =
> javax.persistence.Persistence.createEntityManagerFactory(emfName, m);
>
> The catch is that if Types is specified it must be the complete list
> (as I remember).
>
> hth
> -mike
>
>
>
> >
> > David
> >
> > On Fri, 5 Jun 2009 08:33:19 -0700 (PDT)
> > Pinaki Poddar <[e-mail]> wrote:
> >
> > >
> > > Hi Daryl,
> > >  This is one feature, for a long time, I am interested to be
> > > included in JPA or at least in OpenJPA. Having your queries
> > > *only* in the major compilation unit is a poor idea for usability
> > > point of view and takes away much of the power from tuning a
> > > query a posteriori. However, I had considered the facility
> > > slightly differently than yours. The primary feature that I
> > > considered important in this aspect is to dissociate my queries
> > > from the major compilation units. The compilation units will only
> > > refer them by name.
> > >
> > >  How about the following
> > >   <property name="openjpa.NamedQueryRegistry"
> > > value="path/to/file/that/contains/NamedQueries.java"/>
> > >
> > >   and in code
> > >    Query q =
> > > em.createQuery("ANameThatAppearsInNamedQueryRegsitry");
> > >
> > >
> > > Daryl Stultz wrote:
> > > >
> > > > Hello,
> > > >
> > > > I'm frustrated by the fact that I need to define @NamedQuery and
> > > > others inside my entity classes. I would like to put what I
> > > > consider "logic" where
> > > > I think it's appropriate which is often not with the model. Is
> > > > there a way to programmatically define Named Queries Sql Result
> > > > Set Mappings, etc and register them with the persistence
> > > > engine? I.e. is there any alternative to
> > > > using annotations/xml for defining these things?
> > > >
> > > > String query = "select o...";
> > > > NamedQuery nq = new NamedQuery(query);
> > > > Persistence.registerNamedQuery(nq);
> > > >
> > > > Thanks.
> > > >
> > > > --
> > > > Daryl Stultz
> > > > _____________________________________
> > > > 6 Degrees Software and Consulting, Inc.
> > > > http://www.6degrees.com
> > > > mailto:[e-mail]
> > > >
> > > >
> > >
> > >
> > > -----
> > > Pinaki Poddar                      http://ppoddar.blogspot.com/
> > >
> > > http://www.linkedin.com/in/pinakipoddar
> > > OpenJPA PMC Member/Committer
> > > JPA Expert Group Member
> >
> >

[Daryl Stultz]

On Mon, Jun 8, 2009 at 2:04 PM, Michael Dick <[hidden email]>wrote:

>
> There's no performance advantage to @NamedQueries.


Well that pretty much settles if for me, thanks.



--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:[hidden email]