Hello,
My application uses Tomcat6,derby,spring and OpenJPA 1.20.
My case is stopping derby database and restarting it. And I found even
if I catch the database connection broken exception and create an new
EntityManager successfully after derby restarts, the following
exception stack will be
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
On Fri, Jun 5, 2009 at 11:33 AM, Pinaki Poddar ppod...@apache.org 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.
Hi Luis,
Sorry, the re-written query string : and (r = :a or r = :u) that I
suggested is incorrect in syntax.
The bottom line is that r that ranges over an element collection is not a
valid state_field_path_expression that appears as an operand in comparison
expressions.
Catalina
On Wed, Jun 3,
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
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
On Fri, Jun 5, 2009 at 3:51 PM, Michael Dick michael.d.d...@gmail.comwrote:
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
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
On Fri, Jun 5, 2009 at 3:12 PM, Daryl Stultz da...@6degrees.com wrote:
On Fri, Jun 5, 2009 at 3:51 PM, Michael Dick michael.d.d...@gmail.com
wrote:
Maybe I'm misunderstanding the use case, but the real coupling is the
named
queries to persistence.xml (persistence unit) - not necessarily
On Fri, Jun 5, 2009 at 3:25 PM, David Beer david.m.b...@googlemail.comwrote:
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
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
Hi ,
I want to understand why isDetached is using find. I thought it would be as
simple as reading a boolean variable which is set if detach is caaled on
that particular entity. Furthermore i am not getting the comment below:
// not a part of Query result load. Look into the slices
12 matches
Mail list logo
