Re: svn commit: r513183 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/conf/ openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/ openjpa-persistence/src/main/java/or

2007-03-01 Thread Craig L Russell 


On Mar 1, 2007, at 11:01 AM, Patrick Linskey wrote:


The diff email didn't include enough context for you. This is in the
createContainerEntityManagerFactory() method. It's my contention that
createContainerEntityManagerFactory() will only be invoked by things
that intend to close resources properly.


Cool. Thanks,

Craig


-Patrick

--  
Patrick Linskey

BEA Systems, Inc.

__ 
_
Notice:  This email message, together with any attachments, may  
contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and   
affiliated
entities,  that may be confidential,  proprietary,  copyrighted   
and/or
legally privileged, and is intended solely for the use of the  
individual
or entity named in this message. If you are not the intended  
recipient,
and have received this message in error, please immediately return  
this

by email and then delete it.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 01, 2007 10:38 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: svn commit: r513183 - in
/incubator/openjpa/trunk:
openjpa-kernel/src/main/java/org/apache/openjpa/conf/
openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/
openjpa-persistence/src/main/java/org/apache/openjpa/persistence/

Hi Patrick,

I'm trying to understand how the code knows it's running in an
appserver environment...

Thanks,

Craig

On Mar 1, 2007, at 7:52 AM, Patrick Linskey wrote:


The difference is that in an appserver environment, this

will return a

non-finalizing EM by default, but in a Java SE environment, it will
return a finalizing EM by default. See the last bit of my

last comment

in OPENJPA-160.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.



__


_
Notice:  This email message, together with any attachments, may
contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and
affiliated
entities,  that may be confidential,  proprietary,  copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 28, 2007 10:42 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: svn commit: r513183 - in
/incubator/openjpa/trunk:
openjpa-kernel/src/main/java/org/apache/openjpa/conf/
openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/
openjpa-persistence/src/main/java/org/apache/openjpa/persistence/

Hi Patrick,

I don't quite understand the code that follows. What is the
difference between this code and simply defaulting the

value to non-

finalizing impl?

Craig

On Feb 28, 2007, at 10:31 PM, [EMAIL PROTECTED] wrote:


 PersistenceUnitInfo pui, Map m) {
 PersistenceProductDerivation pd = new
PersistenceProductDerivation();
 try {
+// if the BrokerImpl hasn't been specified,

switch to the

+// non-finalizing one, since anything claiming

to be a

container
+// should be doing proper resource management.
+if (!Configurations.containsProperty(BrokerValue.KEY,
+pui.getProperties())
+&& !Configurations.containsProperty
(BrokerValue.KEY, m)) {
+m.put(BrokerValue.KEY,
BrokerValue.NON_FINALIZING_ALIAS);
+}
+
 ConfigurationProvider cp = pd.load(pui, m);
 if (cp == null)
 return null;


Craig Russell
Architect, Sun Java Enterprise System

http://java.sun.com/products/

jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!




Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/ 
jdo

408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!




Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

RE: [jira] Updated: (OPENJPA-84) Escape sql reserved words in column names

2007-03-01 Thread Patrick Linskey 
> Can you ask OpenJPA to quote ALL identifiers for a particular
> data source?

Not currently, but certainly would be useful once we add quoting
support.

> You might have an identifier (with some databases) that is 
> declared as "a", but if you access it without quotes in a query
> it will be auto-uppercased to A and won't match.

You can tell OpenJPA whether or not the database is case-sensitive. This
is configured in the DBDictionary, and can be fine-tuned by the user.
IOW, you can control whether or not OpenJPA auto-uppercases things.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: Evan Ireland [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 01, 2007 11:32 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: [jira] Updated: (OPENJPA-84) Escape sql reserved 
> words in column names
> 
> Patrick,
> 
> Can you ask OpenJPA to quote ALL identifiers for a particular
> data source?
> 
> You might have an identifier (with some databases) that is 
> declared as "a", but if you access it without quotes in a query
> it will be auto-uppercased to A and won't match.
> 
> Rather than a special case for SQL reserved words, the ability
> to quote all identifiers or quote none is generally more useful.
> 
> > -Original Message-
> > From: Patrick Linskey (JIRA) [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, 1 March 2007 2:19 p.m.
> > To: open-jpa-dev@incubator.apache.org
> > Subject: [jira] Updated: (OPENJPA-84) Escape sql reserved 
> > words in column names
> > 
> > 
> >  [ 
> > https://issues.apache.org/jira/browse/OPENJPA-84?page=com.atla
> > ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> > 
> > Patrick Linskey updated OPENJPA-84:
> > ---
> > 
> > Fix Version/s: 1.0.0
> > 
> > > Escape sql reserved words in column names
> > > -
> > >
> > > Key: OPENJPA-84
> > > URL: 
> > https://issues.apache.org/jira/browse/OPENJPA-84
> > > Project: OpenJPA
> > >  Issue Type: Improvement
> > >  Components: sql
> > >Reporter: Roger Keays
> > > Fix For: 1.0.0
> > >
> > >
> > > OpenJPA does not escape reserved words in SQL queries when 
> > they are used as column names. To escape a reserved name you 
> > just put it in quotes:
> > > INSERT INTO FB_PRIVILEGES (comment, inheritable, level, 
> > role, type, username, item_uuid) ...
> > > on oracle, becomes
> > > INSERT INTO FB_PRIVILEGES ("comment", inheritable, "level", 
> > role, "type", username, item_uuid) ...
> > > Looking at the code in DBDictionary, it appears that the 
> > escaping is done for table and sequence names by appending a 
> > numeral to the name. There isn't really any good reason to do 
> > this instead of quoting the identifier.
> > > table.name identifiers would have to be escaped as 
> > "table"."name" if both table and name were reserved words.
> > 
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> > 
> > 
> 
>

RE: [jira] Updated: (OPENJPA-84) Escape sql reserved words in column names

2007-03-01 Thread Evan Ireland 
Patrick,

Can you ask OpenJPA to quote ALL identifiers for a particular
data source?

You might have an identifier (with some databases) that is 
declared as "a", but if you access it without quotes in a query
it will be auto-uppercased to A and won't match.

Rather than a special case for SQL reserved words, the ability
to quote all identifiers or quote none is generally more useful.

> -Original Message-
> From: Patrick Linskey (JIRA) [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, 1 March 2007 2:19 p.m.
> To: open-jpa-dev@incubator.apache.org
> Subject: [jira] Updated: (OPENJPA-84) Escape sql reserved 
> words in column names
> 
> 
>  [ 
> https://issues.apache.org/jira/browse/OPENJPA-84?page=com.atla
> ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> 
> Patrick Linskey updated OPENJPA-84:
> ---
> 
> Fix Version/s: 1.0.0
> 
> > Escape sql reserved words in column names
> > -
> >
> > Key: OPENJPA-84
> > URL: 
> https://issues.apache.org/jira/browse/OPENJPA-84
> > Project: OpenJPA
> >  Issue Type: Improvement
> >  Components: sql
> >Reporter: Roger Keays
> > Fix For: 1.0.0
> >
> >
> > OpenJPA does not escape reserved words in SQL queries when 
> they are used as column names. To escape a reserved name you 
> just put it in quotes:
> > INSERT INTO FB_PRIVILEGES (comment, inheritable, level, 
> role, type, username, item_uuid) ...
> > on oracle, becomes
> > INSERT INTO FB_PRIVILEGES ("comment", inheritable, "level", 
> role, "type", username, item_uuid) ...
> > Looking at the code in DBDictionary, it appears that the 
> escaping is done for table and sequence names by appending a 
> numeral to the name. There isn't really any good reason to do 
> this instead of quoting the identifier.
> > table.name identifiers would have to be escaped as 
> "table"."name" if both table and name were reserved words.
> 
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
> 
>

Re: OpenJPA & Transaction configuration

2007-03-01 Thread Matthieu Riou 

Thanks for all the feedback, let me remove the @Version (it should really be
a basic field instead as it's app specific) and test it again.

On 3/1/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:


> Here is a link to the source (and no version field):

There is a version field in there. How are you invoking the non-default
constructor? As Abe mentioned, if your version field is set to a value
other than the Java default (0 in this case), OpenJPA will assume that
the instance is detached.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

> -Original Message-
> From: Matthieu Riou [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 28, 2007 9:51 PM
> To: Patrick Linskey
> Cc: open-jpa-dev@incubator.apache.org
> Subject: Re: OpenJPA & Transaction configuration
>
> Here is a link to the source (and no version field):
>
> http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/sr
c/main/java/org/apache/ode/dao/jpa/ProcessDAOImpl.java
>
> How can I try to change the default detach manager? Which one
> should I use instead?
>
> Thanks!
> Matthieu
>
>
> On 2/28/07, Patrick Linskey < [EMAIL PROTECTED]> wrote:
>
>   Can you post the source for ProcessDAOImpl? Also, are
> there any other
>   OpenJPA properties in your configuration? Finally, I'm
> assuming that
>   you're using a somewhat-current 0.9.7-SNAPSHOT. Correct
> me if I'm wrong.
>
>   > But shouldn't I worry about the fact that a brand new
>   > instance is detached? I could be wrong but it looks
>   > like it's more a symptom of
>
>   I believe that you should. I think I remember reading
> something about
>   this recently, but I don't remember the details. My
> suspicion is that
>   you don't have an @Version field, and you're using the
> default detach
>   manager. IIRC, this combination leaves OpenJPA with no
> way to detect a
>   detached object vs. a new object, and we default to
> detached. I thought
>   that we had improved the docs around this at the least;
> certainly, it'd
>   be good to figure out your particulars and make sure
> that this is
>   clearer for others.
>
>   (IIRC, the default detach manager uses a heuristic on
> the value in the
>   version field to determine whether an instance is new
> or detached.
>   OpenJPA supports more flexible detach managers that can
> do fun things
>   like providing useful errors when attempting to
> navigate past the end of
>   a detached object graph, and fine-grained tracking of
> changes made while
>   detached. But it's not serialization-compatible with
> the unenhanced
>   code, meaning that you need to put the enhanced classes
> into your client
>   tier, which I think that we decided was a bad default.)
>
>   -Patrick
>
>   --
>   Patrick Linskey
>   BEA Systems, Inc.
>
>
> __
> _
>   Notice:  This email message, together with any
> attachments, may contain
>   information  of  BEA Systems,  Inc.,  its subsidiaries
> and  affiliated
>   entities,  that may be confidential,  proprietary,
> copyrighted  and/or
>   legally privileged, and is intended solely for the use
> of the individual
>   or entity named in this message. If you are not the
> intended recipient,
>   and have received this message in error, please
> immediately return this
>   by email and then delete it.
>
>   > -Original Message-
>   > From: Matthieu Riou [mailto:[EMAIL PROTECTED]
>   > Sent: Wednesday, February 28, 2007 7:50 PM
>   > To: Pinaki Poddar
>   > Cc: open-jpa-dev@incubator.apache.org
> 
>   > Subject: Re: OpenJPA & Transaction configuration
>   >
>   > Thanks! But shouldn't I worry about the fact that a brand new
>   > instance is
>   > detached? I could be wrong but it looks like it's
> more a symptom of
>   > something wrong in my configuration, no?
>   >
>   > On 2/28/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:
>   > >
>   > >   instead of _em.persist(ret);
>   > > try
>   > >   _em.merge(ret);
>   > >
>   > > as ret is detached instance rather than new.
>   > >
>   > >
>   > >
>   > > Pinaki Poddar
>   > > BEA Systems
>   > > 415.402.7317
>   > >
>   > >
>   > > -Original Message-
>   > > From: Matthieu Ri

RE: svn commit: r513183 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/conf/ openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/ openjpa-persistence/src/main/java/or

2007-03-01 Thread Patrick Linskey 
The diff email didn't include enough context for you. This is in the
createContainerEntityManagerFactory() method. It's my contention that
createContainerEntityManagerFactory() will only be invoked by things
that intend to close resources properly.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 01, 2007 10:38 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: svn commit: r513183 - in 
> /incubator/openjpa/trunk: 
> openjpa-kernel/src/main/java/org/apache/openjpa/conf/ 
> openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/ 
> openjpa-persistence/src/main/java/org/apache/openjpa/persistence/
> 
> Hi Patrick,
> 
> I'm trying to understand how the code knows it's running in an  
> appserver environment...
> 
> Thanks,
> 
> Craig
> 
> On Mar 1, 2007, at 7:52 AM, Patrick Linskey wrote:
> 
> > The difference is that in an appserver environment, this 
> will return a
> > non-finalizing EM by default, but in a Java SE environment, it will
> > return a finalizing EM by default. See the last bit of my 
> last comment
> > in OPENJPA-160.
> >
> > -Patrick
> >
> > -- 
> > Patrick Linskey
> > BEA Systems, Inc.
> >
> > 
> __
>  
> > _
> > Notice:  This email message, together with any attachments, may  
> > contain
> > information  of  BEA Systems,  Inc.,  its subsidiaries  and   
> > affiliated
> > entities,  that may be confidential,  proprietary,  copyrighted   
> > and/or
> > legally privileged, and is intended solely for the use of the  
> > individual
> > or entity named in this message. If you are not the intended  
> > recipient,
> > and have received this message in error, please immediately return  
> > this
> > by email and then delete it.
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >> Sent: Wednesday, February 28, 2007 10:42 PM
> >> To: open-jpa-dev@incubator.apache.org
> >> Subject: Re: svn commit: r513183 - in
> >> /incubator/openjpa/trunk:
> >> openjpa-kernel/src/main/java/org/apache/openjpa/conf/
> >> openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/
> >> openjpa-persistence/src/main/java/org/apache/openjpa/persistence/
> >>
> >> Hi Patrick,
> >>
> >> I don't quite understand the code that follows. What is the
> >> difference between this code and simply defaulting the 
> value to non-
> >> finalizing impl?
> >>
> >> Craig
> >>
> >> On Feb 28, 2007, at 10:31 PM, [EMAIL PROTECTED] wrote:
> >>
> >>>  PersistenceUnitInfo pui, Map m) {
> >>>  PersistenceProductDerivation pd = new
> >>> PersistenceProductDerivation();
> >>>  try {
> >>> +// if the BrokerImpl hasn't been specified,
> >> switch to the
> >>> +// non-finalizing one, since anything claiming
> >> to be a
> >>> container
> >>> +// should be doing proper resource management.
> >>> +if (!Configurations.containsProperty(BrokerValue.KEY,
> >>> +pui.getProperties())
> >>> +&& !Configurations.containsProperty
> >>> (BrokerValue.KEY, m)) {
> >>> +m.put(BrokerValue.KEY,
> >>> BrokerValue.NON_FINALIZING_ALIAS);
> >>> +}
> >>> +
> >>>  ConfigurationProvider cp = pd.load(pui, m);
> >>>  if (cp == null)
> >>>  return null;
> >>
> >> Craig Russell
> >> Architect, Sun Java Enterprise System 
> http://java.sun.com/products/ 
> >> jdo
> >> 408 276-5638 mailto:[EMAIL PROTECTED]
> >> P.S. A good JDO? O, Gasp!
> >>
> >>
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
> 
>

Re: [jira] Updated: (OPENJPA-81) Bad error message when trying to query a Collection relation using dot notation

2007-03-01 Thread Craig L Russell 


On Mar 1, 2007, at 7:55 AM, Patrick Linskey wrote:

My understanding is that "Fix Version(s)" captures both the version  
that

something is scheduled to be fixed in (for unresolved issues) and the
version that something actually was fixed in (for resolved issues).

"Affected Version(s)" identifies the versions that the issue is  
present

in.


This is how other projects use these two fields, and seems reasonable  
to me.




So, I spent some time yesterday afternoon doing JIRA triage. My goals
were to put together something of a reasonable-if-aggressive schedule
for 0.9.7 (presumably the next release), and to adjust priorities
according to the JIRA definitions.

As ever, those changes aren't set in stone; they're just what I  
thought

looked reasonable.


I agree. It should give us a way to quickly see what remains to be  
done. You can ask JIRA to give you a list of unresolved issues for a  
release.


And when we get closer to a release, we can always remove items that  
seem to be out of scope of the release for whatever reason.


Craig


-Patrick

--
Patrick Linskey
BEA Systems, Inc.

__ 
_
Notice:  This email message, together with any attachments, may  
contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and   
affiliated
entities,  that may be confidential,  proprietary,  copyrighted   
and/or
legally privileged, and is intended solely for the use of the  
individual
or entity named in this message. If you are not the intended  
recipient,
and have received this message in error, please immediately return  
this

by email and then delete it.


-Original Message-
From: Kevin Sutter [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 01, 2007 4:55 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [jira] Updated: (OPENJPA-81) Bad error message
when trying to query a Collection relation using dot notation

Patrick,
I'm a little confused with all of these updates you are doing
with the JIRA
Issues.  Most of the updates are related to specifying a Fix
Version of
0.9.7.  Does this mean you are planning on having all of these Issues
resolved for 0.9.7?  Or, do you think this field specifies
which version
needs to be fixed?  There is also an Affected Version field,
which in my
mind, would more closely relate to that idea.

Maybe I'm just not familiar enough with the JIRA usage, but
if you could
explain the reasoning behind these changes, that would be
great.  Thanks.

Kevin

On 2/28/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:



 [


https://issues.apache.org/jira/browse/OPENJPA-81?page=com.atla

ssian.jira.plugin.system.issuetabpanels:all-tabpanel]


Patrick Linskey updated OPENJPA-81:
---

Fix Version/s: 0.9.7


Bad error message when trying to query a Collection

relation using dot

notation





--
-


Key: OPENJPA-81
URL:

https://issues.apache.org/jira/browse/OPENJPA-81

Project: OpenJPA
 Issue Type: Improvement
 Components: diagnostics, query
Environment: openJPA 0.9.7
MySQL 5.0.15
   Reporter: Jakob Braeuchi
   Priority: Minor
Fix For: 0.9.7


the query over the 1:n relationship 'katergorien'
em.createQuery("select distinct k from KategorieGruppe k " +
  "where k.kategorien.bezeichnung like ?1 " +
  "order by k.bezeichnung asc");
uses a wrong alias t2 in the generated SQL:
SELECT DISTINCT t0.id, t0.bezeichnung FROM

ekv2kategoriegruppe t0 INNER

JOIN ekv2kategorie t1 ON t0.id = t1.idGruppe WHERE

(t2.bezeichnung LIKE ?

ESCAPE '\\') ORDER BY t0.bezeichnung ASC [params=(String) F%]

Unknown column 't2.bezeichnung' in 'where clause'


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.






Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: svn commit: r513183 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/conf/ openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/ openjpa-persistence/src/main/java/or

2007-03-01 Thread Craig L Russell 

Hi Patrick,

I'm trying to understand how the code knows it's running in an  
appserver environment...


Thanks,

Craig

On Mar 1, 2007, at 7:52 AM, Patrick Linskey wrote:


The difference is that in an appserver environment, this will return a
non-finalizing EM by default, but in a Java SE environment, it will
return a finalizing EM by default. See the last bit of my last comment
in OPENJPA-160.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

__ 
_
Notice:  This email message, together with any attachments, may  
contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and   
affiliated
entities,  that may be confidential,  proprietary,  copyrighted   
and/or
legally privileged, and is intended solely for the use of the  
individual
or entity named in this message. If you are not the intended  
recipient,
and have received this message in error, please immediately return  
this

by email and then delete it.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 28, 2007 10:42 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: svn commit: r513183 - in
/incubator/openjpa/trunk:
openjpa-kernel/src/main/java/org/apache/openjpa/conf/
openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/
openjpa-persistence/src/main/java/org/apache/openjpa/persistence/

Hi Patrick,

I don't quite understand the code that follows. What is the
difference between this code and simply defaulting the value to non-
finalizing impl?

Craig

On Feb 28, 2007, at 10:31 PM, [EMAIL PROTECTED] wrote:


 PersistenceUnitInfo pui, Map m) {
 PersistenceProductDerivation pd = new
PersistenceProductDerivation();
 try {
+// if the BrokerImpl hasn't been specified,

switch to the

+// non-finalizing one, since anything claiming

to be a

container
+// should be doing proper resource management.
+if (!Configurations.containsProperty(BrokerValue.KEY,
+pui.getProperties())
+&& !Configurations.containsProperty
(BrokerValue.KEY, m)) {
+m.put(BrokerValue.KEY,
BrokerValue.NON_FINALIZING_ALIAS);
+}
+
 ConfigurationProvider cp = pd.load(pui, m);
 if (cp == null)
 return null;


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/ 
jdo

408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!




Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

[jira] Commented: (OPENJPA-20) Query can return embeddable class

2007-03-01 Thread Craig Russell (JIRA) 

[ 
https://issues.apache.org/jira/browse/OPENJPA-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477043
 ] 

Craig Russell commented on OPENJPA-20:
--

I agree with Marc that it's a bug in the doc. The doc could also be reworded 
like "Embedded classes cannot be used as the first entity in the FROM clause of 
a query. They can only be returned by projecting from an entity that embeds 
them."


> Query can return embeddable class
> -
>
> Key: OPENJPA-20
> URL: https://issues.apache.org/jira/browse/OPENJPA-20
> Project: OpenJPA
>  Issue Type: Bug
>  Components: docs
>Reporter: David Wisneski
>Priority: Minor
>
>  part 2 , chapter 4 of user manual on Entity, states that embeddable classes 
> are never returned from a query.  
> This is not true as in the query
>select e.address from EmpBean e
> address could be defined as as embeddable class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: possible to write a JPA Query to that filters both an Entity and its relationship entities?

2007-03-01 Thread Craig L Russell 

Hi Pinaki,

On Feb 26, 2007, at 10:01 AM, Pinaki Poddar wrote:


Respected Sir,
Sorry to disagree. If you fetch Department instances, I think you  
always want the _employees collection to contain all the related  
Employees.
You never want a filtered collection unless you provide a filter  
via some Java behavior.

I agree that department.getEmployees() must return all the employees.

However, i was considering the state of a Department instance in  
memory
that has just been selected by a query.  Which of the native  
(String/int

etc.) field values are populated and which of its related objects are
instantiated is controlled by the currently active fetch plan (if not
explicitly then at least implicitly by 'default' fetch group).


Right.


If the application accesses any unrealized field  of this 'partially
filled' department, then that field is populated irrespective of  
whether

it is in active fetch group or not via a new, separate database access
call.


Right.


In a sense, the fetch plan determines  a 'partial' view of the
'complete' department -- both in terms of its native state and its
relations -- as and when it appears for the first time in memory. In
fact, if the department instance leaves the managed environment via
detachment at that point -- the detached department in a remote  
process

will only have this partially filled 'view'. And, of course, the
application can explictly load any unrealized state of the partial  
view

via any getter method.


Right.


I was trying to draw an equivalence/parallel of this normal fetch
behavior to the use case where a owner object has a high,
multi-cardinalty relationship but only wants a subset of the  
elements of

that relationship. In such a scheme, the traversal on a fetch path
relation (which is now a binary decision) can be further adorned to
support a predicate i.e.
Query query = // a JPQL query that selects a Department based on some
critria
query.getFetchPlan().addField("employees", "yearsOfSevice>10");
Department dept = query.getSingleResult();
// dept will be constructed in memory with a collection of Employees
with yearsOfService>10


The standard way to get the employees with the filter you show is to  
explicitly return the employee instances. The query language does not  
accommodate returning the collection as a result value. One of the  
reasons to exclude this is to disambiguate the result collection as  
being filtered or not. Disallowing return values of collection types  
neatly avoids the issue.



dept.getEmployees();
// now the dept will load a collection of all Employees


Right.

And you can also envision filtering the collection directly via non- 
standard techniques. Given the collection, that might not be fully  
instantiated, you can pass that collection to a proprietary method  
that does the filtering in the database.


Of course, the suggested alternative approach where the application
explictly constructs this partial/filtered multi-cardinality  
relatinship

by choosing the elements via query is feasible and available right now
with current features.


Right.

Craig



Pinaki Poddar
BEA Systems
415.402.7317


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, February 23, 2007 8:32 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: possible to write a JPA Query to that filters both an
Entity and its relationship entities?


On Feb 23, 2007, at 7:49 PM, Pinaki Poddar wrote:


One way to realize a owner object with a partially filled
multi-cardinality relationship is to expand fetchplan concept. For
example, if we consider a Department of 100 Employees of which  
only 20



are oldtimers, then a query can select the particular Department from
the datastore but to realize that Department as a Java object in
memory with only 20 senior Employees in _employees collection will
need to tune the fetch plan acconrdingly.
In JDO, fetch plan is specified to certain details to extract a  
subset
of native states and subset of relationships. JPA does not yet  
specify

fetch plan, but OpenJPA does via @FetchGroup extension. However
currently, no filtering criterion is applied to filter the content
while a particular relationship path is traversed. It is a
all-or-nothing affair. Either Department is fetched with all its 100
Employees or the Employees relation is not traversed at all. The only
control available now is to specify which native states and
relationship will be considered for fetching and in case of recursive
relationship how many times a particular relation path will be
traversed.
Essentially query and fecth paths are working in conjunction -- query
selects the root object and fetch plan decides which subset of the
closure of this root object is realized in memory.  It will surely be
a useful feature to consider expanding fetch plan with filtering
criteria.


Sorry to disagree. If you fetch Department instances, I think you  
always
want the _employees collection to contain

RE: [jira] Updated: (OPENJPA-81) Bad error message when trying to query a Collection relation using dot notation

2007-03-01 Thread Patrick Linskey 
BTW, sorry about all the emails. Halfway through my bulk changes, I
realized that I could turn off email spam for bulk changes.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: Kevin Sutter [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 01, 2007 9:27 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: [jira] Updated: (OPENJPA-81) Bad error message 
> when trying to query a Collection relation using dot notation
> 
> Patrick,
> Sounds good.  I like the aggressive schedule idea.  I hope we 
> can pull it
> off...  :-)
> 
> Kevin
> 
> On 3/1/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
> >
> > My understanding is that "Fix Version(s)" captures both the 
> version that
> > something is scheduled to be fixed in (for unresolved 
> issues) and the
> > version that something actually was fixed in (for resolved issues).
> >
> > "Affected Version(s)" identifies the versions that the 
> issue is present
> > in.
> >
> > So, I spent some time yesterday afternoon doing JIRA 
> triage. My goals
> > were to put together something of a 
> reasonable-if-aggressive schedule
> > for 0.9.7 (presumably the next release), and to adjust priorities
> > according to the JIRA definitions.
> >
> > As ever, those changes aren't set in stone; they're just 
> what I thought
> > looked reasonable.
> >
> > -Patrick
> >
> > --
> > Patrick Linskey
> > BEA Systems, Inc.
> >
> > 
> __
> _
> > Notice:  This email message, together with any attachments, 
> may contain
> > information  of  BEA Systems,  Inc.,  its subsidiaries  and 
>  affiliated
> > entities,  that may be confidential,  proprietary,  
> copyrighted  and/or
> > legally privileged, and is intended solely for the use of 
> the individual
> > or entity named in this message. If you are not the 
> intended recipient,
> > and have received this message in error, please immediately 
> return this
> > by email and then delete it.
> >
> > > -Original Message-
> > > From: Kevin Sutter [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, March 01, 2007 4:55 AM
> > > To: open-jpa-dev@incubator.apache.org
> > > Subject: Re: [jira] Updated: (OPENJPA-81) Bad error message
> > > when trying to query a Collection relation using dot notation
> > >
> > > Patrick,
> > > I'm a little confused with all of these updates you are doing
> > > with the JIRA
> > > Issues.  Most of the updates are related to specifying a Fix
> > > Version of
> > > 0.9.7.  Does this mean you are planning on having all of 
> these Issues
> > > resolved for 0.9.7?  Or, do you think this field specifies
> > > which version
> > > needs to be fixed?  There is also an Affected Version field,
> > > which in my
> > > mind, would more closely relate to that idea.
> > >
> > > Maybe I'm just not familiar enough with the JIRA usage, but
> > > if you could
> > > explain the reasoning behind these changes, that would be
> > > great.  Thanks.
> > >
> > > Kevin
> > >
> > > On 2/28/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >  [
> > > >
> > > https://issues.apache.org/jira/browse/OPENJPA-81?page=com.atla
> > ssian.jira.plugin.system.issuetabpanels:all-tabpanel]
> > > >
> > > > Patrick Linskey updated OPENJPA-81:
> > > > ---
> > > >
> > > > Fix Version/s: 0.9.7
> > > >
> > > > > Bad error message when trying to query a Collection
> > > relation using dot
> > > > notation
> > > > >
> > > >
> > > --
> > > -
> > > > >
> > > > > Key: OPENJPA-81
> > > > > URL:
> > > https://issues.apache.org/jira/browse/OPENJPA-81
> > > > > Project: OpenJPA
> > > > >  Issue Type: Improvement
> > > > >  Components: diagnostics, query
> > > > > Environment: openJPA 0.9.7
> > > > > MySQL 5.0.15
> > > > >Reporter: Jakob Braeuchi
> > > > >Priority: Minor
> > > > > Fix For: 0.9.7
> > > > >
> > > > >
> > > > > the query over the 1:n relationship 'katergorien'
> > > > > em.createQuery("select distinct k from KategorieGruppe k " +
> > > > >   "where k.kategorien.bezeichnung 
> like ?1 " +
> > > > >   "order by k.bezeichnung asc");
> > > > > uses a wrong alias t2 in the generated SQL:
> > > > > SELECT DISTINCT t0.id, t0.bezeichnung FROM
> >

Re: [jira] Updated: (OPENJPA-81) Bad error message when trying to query a Collection relation using dot notation

2007-03-01 Thread Kevin Sutter 

Patrick,
Sounds good.  I like the aggressive schedule idea.  I hope we can pull it
off...  :-)

Kevin

On 3/1/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:


My understanding is that "Fix Version(s)" captures both the version that
something is scheduled to be fixed in (for unresolved issues) and the
version that something actually was fixed in (for resolved issues).

"Affected Version(s)" identifies the versions that the issue is present
in.

So, I spent some time yesterday afternoon doing JIRA triage. My goals
were to put together something of a reasonable-if-aggressive schedule
for 0.9.7 (presumably the next release), and to adjust priorities
according to the JIRA definitions.

As ever, those changes aren't set in stone; they're just what I thought
looked reasonable.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

> -Original Message-
> From: Kevin Sutter [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 01, 2007 4:55 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: [jira] Updated: (OPENJPA-81) Bad error message
> when trying to query a Collection relation using dot notation
>
> Patrick,
> I'm a little confused with all of these updates you are doing
> with the JIRA
> Issues.  Most of the updates are related to specifying a Fix
> Version of
> 0.9.7.  Does this mean you are planning on having all of these Issues
> resolved for 0.9.7?  Or, do you think this field specifies
> which version
> needs to be fixed?  There is also an Affected Version field,
> which in my
> mind, would more closely relate to that idea.
>
> Maybe I'm just not familiar enough with the JIRA usage, but
> if you could
> explain the reasoning behind these changes, that would be
> great.  Thanks.
>
> Kevin
>
> On 2/28/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:
> >
> >
> >  [
> >
> https://issues.apache.org/jira/browse/OPENJPA-81?page=com.atla
ssian.jira.plugin.system.issuetabpanels:all-tabpanel]
> >
> > Patrick Linskey updated OPENJPA-81:
> > ---
> >
> > Fix Version/s: 0.9.7
> >
> > > Bad error message when trying to query a Collection
> relation using dot
> > notation
> > >
> >
> --
> -
> > >
> > > Key: OPENJPA-81
> > > URL:
> https://issues.apache.org/jira/browse/OPENJPA-81
> > > Project: OpenJPA
> > >  Issue Type: Improvement
> > >  Components: diagnostics, query
> > > Environment: openJPA 0.9.7
> > > MySQL 5.0.15
> > >Reporter: Jakob Braeuchi
> > >Priority: Minor
> > > Fix For: 0.9.7
> > >
> > >
> > > the query over the 1:n relationship 'katergorien'
> > > em.createQuery("select distinct k from KategorieGruppe k " +
> > >   "where k.kategorien.bezeichnung like ?1 " +
> > >   "order by k.bezeichnung asc");
> > > uses a wrong alias t2 in the generated SQL:
> > > SELECT DISTINCT t0.id, t0.bezeichnung FROM
> ekv2kategoriegruppe t0 INNER
> > JOIN ekv2kategorie t1 ON t0.id = t1.idGruppe WHERE
> (t2.bezeichnung LIKE ?
> > ESCAPE '\\') ORDER BY t0.bezeichnung ASC [params=(String) F%]
> > > Unknown column 't2.bezeichnung' in 'where clause'
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>

RE: [jira] Updated: (OPENJPA-81) Bad error message when trying to query a Collection relation using dot notation

2007-03-01 Thread Patrick Linskey 
My understanding is that "Fix Version(s)" captures both the version that
something is scheduled to be fixed in (for unresolved issues) and the
version that something actually was fixed in (for resolved issues).

"Affected Version(s)" identifies the versions that the issue is present
in.

So, I spent some time yesterday afternoon doing JIRA triage. My goals
were to put together something of a reasonable-if-aggressive schedule
for 0.9.7 (presumably the next release), and to adjust priorities
according to the JIRA definitions.

As ever, those changes aren't set in stone; they're just what I thought
looked reasonable.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: Kevin Sutter [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 01, 2007 4:55 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: [jira] Updated: (OPENJPA-81) Bad error message 
> when trying to query a Collection relation using dot notation
> 
> Patrick,
> I'm a little confused with all of these updates you are doing 
> with the JIRA
> Issues.  Most of the updates are related to specifying a Fix 
> Version of
> 0.9.7.  Does this mean you are planning on having all of these Issues
> resolved for 0.9.7?  Or, do you think this field specifies 
> which version
> needs to be fixed?  There is also an Affected Version field, 
> which in my
> mind, would more closely relate to that idea.
> 
> Maybe I'm just not familiar enough with the JIRA usage, but 
> if you could
> explain the reasoning behind these changes, that would be 
> great.  Thanks.
> 
> Kevin
> 
> On 2/28/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:
> >
> >
> >  [
> > 
> https://issues.apache.org/jira/browse/OPENJPA-81?page=com.atla
ssian.jira.plugin.system.issuetabpanels:all-tabpanel]
> >
> > Patrick Linskey updated OPENJPA-81:
> > ---
> >
> > Fix Version/s: 0.9.7
> >
> > > Bad error message when trying to query a Collection 
> relation using dot
> > notation
> > >
> > 
> --
> -
> > >
> > > Key: OPENJPA-81
> > > URL: 
> https://issues.apache.org/jira/browse/OPENJPA-81
> > > Project: OpenJPA
> > >  Issue Type: Improvement
> > >  Components: diagnostics, query
> > > Environment: openJPA 0.9.7
> > > MySQL 5.0.15
> > >Reporter: Jakob Braeuchi
> > >Priority: Minor
> > > Fix For: 0.9.7
> > >
> > >
> > > the query over the 1:n relationship 'katergorien'
> > > em.createQuery("select distinct k from KategorieGruppe k " +
> > >   "where k.kategorien.bezeichnung like ?1 " +
> > >   "order by k.bezeichnung asc");
> > > uses a wrong alias t2 in the generated SQL:
> > > SELECT DISTINCT t0.id, t0.bezeichnung FROM 
> ekv2kategoriegruppe t0 INNER
> > JOIN ekv2kategorie t1 ON t0.id = t1.idGruppe WHERE 
> (t2.bezeichnung LIKE ?
> > ESCAPE '\\') ORDER BY t0.bezeichnung ASC [params=(String) F%]
> > > Unknown column 't2.bezeichnung' in 'where clause'
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>

RE: svn commit: r513183 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/conf/ openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/ openjpa-persistence/src/main/java/or

2007-03-01 Thread Patrick Linskey 
The difference is that in an appserver environment, this will return a
non-finalizing EM by default, but in a Java SE environment, it will
return a finalizing EM by default. See the last bit of my last comment
in OPENJPA-160.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, February 28, 2007 10:42 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: svn commit: r513183 - in 
> /incubator/openjpa/trunk: 
> openjpa-kernel/src/main/java/org/apache/openjpa/conf/ 
> openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/ 
> openjpa-persistence/src/main/java/org/apache/openjpa/persistence/
> 
> Hi Patrick,
> 
> I don't quite understand the code that follows. What is the  
> difference between this code and simply defaulting the value to non- 
> finalizing impl?
> 
> Craig
> 
> On Feb 28, 2007, at 10:31 PM, [EMAIL PROTECTED] wrote:
> 
> >  PersistenceUnitInfo pui, Map m) {
> >  PersistenceProductDerivation pd = new  
> > PersistenceProductDerivation();
> >  try {
> > +// if the BrokerImpl hasn't been specified, 
> switch to the
> > +// non-finalizing one, since anything claiming 
> to be a  
> > container
> > +// should be doing proper resource management.
> > +if (!Configurations.containsProperty(BrokerValue.KEY,
> > +pui.getProperties())
> > +&& !Configurations.containsProperty 
> > (BrokerValue.KEY, m)) {
> > +m.put(BrokerValue.KEY,  
> > BrokerValue.NON_FINALIZING_ALIAS);
> > +}
> > +
> >  ConfigurationProvider cp = pd.load(pui, m);
> >  if (cp == null)
> >  return null;
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
> 
>

RE: OpenJPA & Transaction configuration

2007-03-01 Thread Patrick Linskey 
> Here is a link to the source (and no version field):

There is a version field in there. How are you invoking the non-default
constructor? As Abe mentioned, if your version field is set to a value
other than the Java default (0 in this case), OpenJPA will assume that
the instance is detached.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -Original Message-
> From: Matthieu Riou [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, February 28, 2007 9:51 PM
> To: Patrick Linskey
> Cc: open-jpa-dev@incubator.apache.org
> Subject: Re: OpenJPA & Transaction configuration
> 
> Here is a link to the source (and no version field):
> 
> http://svn.apache.org/repos/asf/incubator/ode/trunk/dao-jpa/sr
c/main/java/org/apache/ode/dao/jpa/ProcessDAOImpl.java 
> 
> How can I try to change the default detach manager? Which one 
> should I use instead?
> 
> Thanks!
> Matthieu
> 
> 
> On 2/28/07, Patrick Linskey < [EMAIL PROTECTED]> wrote:
> 
>   Can you post the source for ProcessDAOImpl? Also, are 
> there any other 
>   OpenJPA properties in your configuration? Finally, I'm 
> assuming that
>   you're using a somewhat-current 0.9.7-SNAPSHOT. Correct 
> me if I'm wrong.
>   
>   > But shouldn't I worry about the fact that a brand new 
>   > instance is detached? I could be wrong but it looks
>   > like it's more a symptom of
>   
>   I believe that you should. I think I remember reading 
> something about
>   this recently, but I don't remember the details. My 
> suspicion is that 
>   you don't have an @Version field, and you're using the 
> default detach
>   manager. IIRC, this combination leaves OpenJPA with no 
> way to detect a
>   detached object vs. a new object, and we default to 
> detached. I thought 
>   that we had improved the docs around this at the least; 
> certainly, it'd
>   be good to figure out your particulars and make sure 
> that this is
>   clearer for others.
>   
>   (IIRC, the default detach manager uses a heuristic on 
> the value in the 
>   version field to determine whether an instance is new 
> or detached.
>   OpenJPA supports more flexible detach managers that can 
> do fun things
>   like providing useful errors when attempting to 
> navigate past the end of
>   a detached object graph, and fine-grained tracking of 
> changes made while
>   detached. But it's not serialization-compatible with 
> the unenhanced
>   code, meaning that you need to put the enhanced classes 
> into your client 
>   tier, which I think that we decided was a bad default.)
>   
>   -Patrick
>   
>   --
>   Patrick Linskey
>   BEA Systems, Inc.
>   
>   
> __
> _
>   Notice:  This email message, together with any 
> attachments, may contain 
>   information  of  BEA Systems,  Inc.,  its subsidiaries  
> and  affiliated
>   entities,  that may be confidential,  proprietary,  
> copyrighted  and/or
>   legally privileged, and is intended solely for the use 
> of the individual 
>   or entity named in this message. If you are not the 
> intended recipient,
>   and have received this message in error, please 
> immediately return this
>   by email and then delete it.
>   
>   > -Original Message- 
>   > From: Matthieu Riou [mailto:[EMAIL PROTECTED]
>   > Sent: Wednesday, February 28, 2007 7:50 PM
>   > To: Pinaki Poddar
>   > Cc: open-jpa-dev@incubator.apache.org 
>  
>   > Subject: Re: OpenJPA & Transaction configuration
>   >
>   > Thanks! But shouldn't I worry about the fact that a brand new
>   > instance is
>   > detached? I could be wrong but it looks like it's 
> more a symptom of 
>   > something wrong in my configuration, no?
>   >
>   > On 2/28/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote:
>   > >
>   > >   instead of _em.persist(ret);
>   > > try 
>   > >   _em.merge(ret);
>   > >
>   > > as ret is detached instance rather than new.
>   > >
>   > >
>   > >
>   > > Pinaki Poddar
>   > > BEA Systems
>   > > 415.402.7317
>   > >
>   > >
>   > > -Original Message-
>   > > From: Matthieu Riou [mailto:[EMAIL PROTECTED]
>   > > Sent: Wednesday, February 28, 2007 6:29 PM 
>

Re: OpenJPA & Transaction configuration

2007-03-01 Thread Abe White 
If you set the version field of an instance to a non-default value,  
OpenJPA assumes the instance was detached, or that you're actively  
trying to make it behave as a detached instance.

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Re: [jira] Updated: (OPENJPA-81) Bad error message when trying to query a Collection relation using dot notation

2007-03-01 Thread Kevin Sutter 

Patrick,
I'm a little confused with all of these updates you are doing with the JIRA
Issues.  Most of the updates are related to specifying a Fix Version of
0.9.7.  Does this mean you are planning on having all of these Issues
resolved for 0.9.7?  Or, do you think this field specifies which version
needs to be fixed?  There is also an Affected Version field, which in my
mind, would more closely relate to that idea.

Maybe I'm just not familiar enough with the JIRA usage, but if you could
explain the reasoning behind these changes, that would be great.  Thanks.

Kevin

On 2/28/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:



 [
https://issues.apache.org/jira/browse/OPENJPA-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]

Patrick Linskey updated OPENJPA-81:
---

Fix Version/s: 0.9.7

> Bad error message when trying to query a Collection relation using dot
notation
>
---
>
> Key: OPENJPA-81
> URL: https://issues.apache.org/jira/browse/OPENJPA-81
> Project: OpenJPA
>  Issue Type: Improvement
>  Components: diagnostics, query
> Environment: openJPA 0.9.7
> MySQL 5.0.15
>Reporter: Jakob Braeuchi
>Priority: Minor
> Fix For: 0.9.7
>
>
> the query over the 1:n relationship 'katergorien'
> em.createQuery("select distinct k from KategorieGruppe k " +
>   "where k.kategorien.bezeichnung like ?1 " +
>   "order by k.bezeichnung asc");
> uses a wrong alias t2 in the generated SQL:
> SELECT DISTINCT t0.id, t0.bezeichnung FROM ekv2kategoriegruppe t0 INNER
JOIN ekv2kategorie t1 ON t0.id = t1.idGruppe WHERE (t2.bezeichnung LIKE ?
ESCAPE '\\') ORDER BY t0.bezeichnung ASC [params=(String) F%]
> Unknown column 't2.bezeichnung' in 'where clause'

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-23) -418 sqlexception using DB2 and EJB QL with SQRT or MOD

2007-03-01 Thread Marc Prud'hommeaux (JIRA) 

 [ 
https://issues.apache.org/jira/browse/OPENJPA-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Prud'hommeaux resolved OPENJPA-23.
---

Resolution: Fixed
  Assignee: Marc Prud'hommeaux

I am fairly certain this was fixed a while ago (around change #497715).

> -418 sqlexception using DB2 and EJB QL with SQRT or MOD
> ---
>
> Key: OPENJPA-23
> URL: https://issues.apache.org/jira/browse/OPENJPA-23
> Project: OpenJPA
>  Issue Type: Bug
>Reporter: David Wisneski
> Assigned To: Marc Prud'hommeaux
> Fix For: 0.9.7
>
>
> generated SQL is missing CAST function to indicate type of ?
>  EJB QL :  select e from EmpBean e where mod(e.empid,5)=0 
> DB2 SQL error: SQLCODE: -418, SQLSTATE: 42610, SQLERRMC: null {prepstmnt 
> 1046232668 
> SELECT t0.empid, t0.bonus, t1.deptno, t1.budget, t1.name, t0.execLevel, 
> t0.hireDate, t0.hireTime, t0.hireTimestamp,
> t0.home, t0.isManager, t0.name, t0.salary, t0.work FROM EmpBean t0 LEFT OUTER 
> JOIN DeptBean t1 ON t0.dept_deptno = t1.deptno
> WHERE (MOD(t0.empid, ?) = ?)
> db2 sql compiler is not able to resolve type of expression (MOD(t0.empid, ?) 
> = ?.  This expression should be 
> MOD(t0.empid, cast((?) as integer) ) = ?.or 
> MOD(t0.empid, 5) = 0 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.