date:20070418


Hi Eddie,

On Apr 18, 2007, at 8:46 AM, Eddie O'Neil wrote:


The release is looking good with two items that should be addressed
and some nits.  :)

Major issues:
- Mike's GPG key is present in site/docs/KEYS but this file needs to
be copied to http://incubator.apache.org/openjpa/KEYS as well.  This
will make it easier to verify releases and matches the instructions on
the download page.


I agree. This doesn't hold up the release since it's a parallel  
activity.



...



Minor issues:
- The Maven2 repo contains two directories that probably shouldn't be
part of the release --
examples/ and tck/


 If you're using maven, it's unlikely that these will be of  
interest, but I don't have any problem with including these in the  
maven repo, regardless of how useful (or not) they might be there.



- The .rsrc files don't have licenses -- we've discussed this before
(even in this thread!).  This isn't a big deal, just expect the iPMC
to bring it up again.


It might be well to post the results of our discussion with the VOTE  
for IPMC to approve release, just so people are aware that we know  
about it and have discussed it and our mentors agree that it's going  
to be fixed but not today.



- The JPA XSDs are CDDL licensed and are included in the distribution.
IMHO, these should be cleanroom'ed so that the question just goes
away.
Like the .rsrc files, this has come up before and not been an
issue.


I don't believe that it's possible to clean room these files. They  
have a perfectly compatible license. These are specified reference  
files, not an implementation that can have independent IP. So I don't  
think it's worthwhile to try to clean room them.



...



 Comments welcome, but let's work on addressing the first two.

Eddie



On 4/17/07, Kevin Sutter [EMAIL PROTECTED] wrote:

+1 for the 0.9.7 release.

On 4/16/07, Patrick Linskey [EMAIL PROTECTED] wrote:

  openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/
  resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc
  don't know: This is a dtd describing document type schemas. It
  doesn't appear to be generated and certainly has some IP in it.

 I think that our parser doesn't deal with comments for this type.

  openjpa-project-0.9.7-incubating-source/openjpa-persistence-jdbc/
  derby.log
  ok: This should be cleaned up for future releases but has no IP

 We should just move this to the target directory.

 I'm anxiously awaiting the day that Apache decides that it  
really is

 sufficient to describe licensing terms at the packaging unit level,
 rather than the individual file level.

 -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: Monday, April 16, 2007 11:40 AM
  To: open-jpa-dev@incubator.apache.org
  Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
 
  +1 for release
 
  I ran Robert's Donkin's RAT program on the release, and it
  reported a
  few anomalies:
 
  No license:
  openjpa-project-0.9.7-incubating-source/CHANGES.txt
  ok: No IP here
 
  openjpa-project-0.9.7-incubating-source/RELEASE-NOTES.html
  don't know: I'd approve it but others in the Incubator PMC
  might feel
  otherwise.
 
  openjpa-project-0.9.7-incubating-source/openjpa-integration/tck/
  windows-replacefilter.properties
  ok: No IP here
 
  openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/
  resources/org/apache/openjpa/jdbc/meta/java-keywords.rsrc
  ok: No IP here
 
  openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/
  resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc
  don't know: This is a dtd describing document type schemas. It
  doesn't appear to be generated and certainly has some IP in it.
 
  openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/
  resources/org/apache/openjpa/jdbc/sql/sql-keywords.rsrc
  ok: No IP here
 
  openjpa-project-0.9.7-incubating-source/openjpa-persistence/ 
src/main/
  resources/META-INF/services/ 
javax.persistence.spi.PersistenceProvider

  ok: No IP here
 
  openjpa-project-0.9.7-incubating-source/openjpa-persistence/ 
src/main/

  resources/org/apache/openjpa/persistence/orm-xsd.rsrc
  ok: This is a copy of the official JPA schema under CDDL that is
  properly attributed in LICENSE.txt
 
  openjpa-project-0.9.7-incubating-source/openjpa-persistence/ 
src/main/

Re: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-18 Thread Ritika Maheshwari

1. OK I think I will open a new issue for the bug
2. I will redo the formatting
3.To be able to use DBDictionary method we will have to change the signature
of the

toSelect(SQLBuffer selects, JDBCFetchConfiguration fetch,SQLBuffer from,
SQLBuffer where, SQLBuffer group,SQLBuffer having, SQLBuffer
order,*boolean*distinct,
*boolean* forUpdate, *long* start, *long* end)

to include a boolean flag subselect which will be computed in the

SQLBuffer toSelect(Select sel, *boolean* forUpdate,JDBCFetchConfiguration
fetch)

since we have the handle to the Select here.This needs to be done only for
DB2 because only in case of DB2 even if forUpdate is false( which is set to
false correctly for subselects by SQLBuffer.resolveSubselects()) we need to
append a FOR READ ONLY clause except in case of subselects.In other
databases if forUpdate is false we do not append any update or FOR READ ONLY
CLAUSE. So this situaton is unique to db2.

So Essentially we need to pass this subselect flag to getForUpdateClause
method.I am not sure how would we do that without overriding the method in
DB2Dictionary or chnaging the signatures in DBDictionary which would affect
many other files

On 4/17/07, Patrick Linskey (JIRA) [EMAIL PROTECTED] wrote:

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

Patrick Linskey commented on OPENJPA-182:
-

Some comments:

1. I don't think that we should be doing work on resolved issues. So, this
should be re-opened, or (preferably) a new issue should be opened for this
new bug.

2. The patch you attached does not use OpenJPA-style formatting. We don't
have a style guide spelled out as well as we probably should, but we always
put spaces after commas, we indent 4 spaces on continuation lines, and we
put a space between an 'if' and the open paren.

3. It's a shame to have to do all this code duplication between
DBDictionary and DB2Dictionary. To what extent can we refactor
DBDictionary's methods to make this concept work out better for
DB2Dictionary?

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

Key: OPENJPA-182
URL: https://issues.apache.org/jira/browse/OPENJPA-182
Project: OpenJPA
Issue Type: New Feature
Components: jdbc
Environment: db2 database driver for zOS, AS400, Unix, Windows,
Linux
Reporter: David Wisneski
Fix For: 0.9.7

Attachments: JIRA182-subselect.patch, OPENJPA-182.patch,
OPENJPA-182.patch, openJPA182.patch, openjpa182TestCase.jar

A while back we changed the syntax of update locking from FOR UPDATE
OF to WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required
because
1. if isolation=serializable is configured, then the syntax should
be WITH RR USE AND KEEP UDPATE LOCKS
2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE
AND KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because
DB2/400 only supports read or exclusive locks.
3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses.
So we change supportsLockingWithSelectRange = true in the
AbstractDB2Dictionary class and change the DB2Dictionary to append the
correct LOCKS syntax depending on vendor, release and isolation level.

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

[jira] Created: (OPENJPA-222) FOR READ ONLY clause getting generated for subselects

2007-04-18 Thread Ritika Maheshwari (JIRA)

FOR READ ONLY clause getting generated for subselects
-

 Key: OPENJPA-222
 URL: https://issues.apache.org/jira/browse/OPENJPA-222
 Project: OpenJPA
  Issue Type: Bug
  Components: jpa
Affects Versions: 0.9.7
Reporter: Ritika Maheshwari


FOR READ ONLY clause is generated for subselects in DB2. which throws a DB2 
Exception

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

RE: [VOTE] publish openjpa 0.9.7-incubating release

 [eko] Yeah, you're right that neithre of these are big deals 
 -- just empty directories.  I did wonder if the TCK directory 
 had anything that TCK-related that shouldn't be public (like 
 how to run it), but I'll defer to you and Geir here.

The TCK dir only contains the bootstrap / glue to invoke the TCK from
within our build system, and not the TCK itself.

-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: Eddie O'Neil [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 18, 2007 9:49 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
 
 Craig--
 
   Thanks for the comments -- comments on comments below.  :)
 
 Eddie
 
 
 On 4/18/07, Craig L Russell [EMAIL PROTECTED] wrote:
  Hi Eddie,
 
  On Apr 18, 2007, at 8:46 AM, Eddie O'Neil wrote:
 
   The release is looking good with two items that should be 
 addressed 
   and some nits.  :)
  
   Major issues:
   - Mike's GPG key is present in site/docs/KEYS but this 
 file needs to 
   be copied to http://incubator.apache.org/openjpa/KEYS as 
 well.  This 
   will make it easier to verify releases and matches the 
 instructions 
   on the download page.
 
  I agree. This doesn't hold up the release since it's a parallel 
  activity.
 
 
 [eko] Agreed -- this is just a file copy that should just be 
 done before calling for an iPMC vote.
 
   ...
 
   Minor issues:
   - The Maven2 repo contains two directories that probably 
 shouldn't 
   be part of the release -- examples/ and tck/
 
If you're using maven, it's unlikely that these will be 
 of interest, 
  but I don't have any problem with including these in the 
 maven repo, 
  regardless of how useful (or not) they might be there.
 
 
 [eko] Yeah, you're right that neithre of these are big deals 
 -- just empty directories.  I did wonder if the TCK directory 
 had anything that TCK-related that shouldn't be public (like 
 how to run it), but I'll defer to you and Geir here.
 
   - The .rsrc files don't have licenses -- we've discussed 
 this before 
   (even in this thread!).  This isn't a big deal, just 
 expect the iPMC 
   to bring it up again.
 
  It might be well to post the results of our discussion with 
 the VOTE 
  for IPMC to approve release, just so people are aware that we know 
  about it and have discussed it and our mentors agree that 
 it's going 
  to be fixed but not today.
 
 
 [eko] Agreed -- we can also just send IDs from the last vote 
 where we addressed this.
 
   - The JPA XSDs are CDDL licensed and are included in the 
 distribution.
   IMHO, these should be cleanroom'ed so that the question just goes 
   away.
   Like the .rsrc files, this has come up before and not 
 been an issue.
 
  I don't believe that it's possible to clean room these files. They 
  have a perfectly compatible license. These are specified reference 
  files, not an implementation that can have independent IP. 
 So I don't 
  think it's worthwhile to try to clean room them.
 
 
 [eko] Okay -- the reason I keep bringing these up is because 
 of Cliff's 3rd party licensing site and how it makes a 
 distinction between src / binary wrt CDDL:
   http://people.apache.org/~cliffs/3party.html
 We're definitely compliant with the NOTICE part of this.
 
 
   ...
 
Comments welcome, but let's work on addressing the first two.
  
   Eddie
  
  
  
   On 4/17/07, Kevin Sutter [EMAIL PROTECTED] wrote:
   +1 for the 0.9.7 release.
  
   On 4/16/07, Patrick Linskey [EMAIL PROTECTED] wrote:
   
 
 openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/
 resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc
 don't know: This is a dtd describing document type 
 schemas. 
 It doesn't appear to be generated and certainly has 
 some IP in it.
   
I think that our parser doesn't deal with comments for 
 this type.
   
 
 openjpa-project-0.9.7-incubating-source/openjpa-persistence-jdb
 c/
 derby.log
 ok: This should be cleaned up for future releases 
 but has no IP
   
We should just move this to the target directory.
   
I'm anxiously awaiting the day that Apache decides that it
   really is
sufficient to describe licensing terms at the packaging unit 
level, rather than the individual file level.
   
-Patrick
   
--
Patrick Linskey
BEA Systems, Inc.
   
   
   
 ___

RE: [VOTE] publish openjpa 0.9.7-incubating release

 - The binary distribution contains a new JAR file whose 
 license is unclear; this is:
   binary-dist/lib/docbook-xsl-1.67.2.zip

That dependency is unnecessary -- it's needed to build the docs, but not
by the runtime.

-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: Eddie O'Neil [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 18, 2007 8:46 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
 
 The release is looking good with two items that should be 
 addressed and some nits.  :)
 
 Major issues:
 - Mike's GPG key is present in site/docs/KEYS but this file 
 needs to be copied to 
 http://incubator.apache.org/openjpa/KEYS as well.  This will 
 make it easier to verify releases and matches the 
 instructions on the download page.
 - The binary distribution contains a new JAR file whose 
 license is unclear; this is:
   binary-dist/lib/docbook-xsl-1.67.2.zip
 
 Minor issues:
 - The Maven2 repo contains two directories that probably 
 shouldn't be part of the release -- examples/ and tck/
 - The .rsrc files don't have licenses -- we've discussed this 
 before (even in this thread!).  This isn't a big deal, just 
 expect the iPMC to bring it up again.
 - The JPA XSDs are CDDL licensed and are included in the distribution.
  IMHO, these should be cleanroom'ed so that the question just 
 goes away.  Like the .rsrc files, this has come up before and 
 not been an issue.
 - The .zip distribution contains .asc files for the .md5 and 
 .sha1 files, which are unnecessary.
 - The source distribution contains a derby.log file at:
   source-dist/openjpa-persistence-jdbc/derby.log
 
   Comments welcome, but let's work on addressing the first two.
 
 Eddie
 
 
 
 On 4/17/07, Kevin Sutter [EMAIL PROTECTED] wrote:
  +1 for the 0.9.7 release.
 
  On 4/16/07, Patrick Linskey [EMAIL PROTECTED] wrote:
  
openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/
resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc
don't know: This is a dtd describing document type 
 schemas. It 
doesn't appear to be generated and certainly has some IP in it.
  
   I think that our parser doesn't deal with comments for this type.
  

 openjpa-project-0.9.7-incubating-source/openjpa-persistence-jdbc/
derby.log
ok: This should be cleaned up for future releases but has no IP
  
   We should just move this to the target directory.
  
   I'm anxiously awaiting the day that Apache decides that 
 it really is 
   sufficient to describe licensing terms at the packaging 
 unit level, 
   rather than the individual file level.
  
   -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: Monday, April 16, 2007 11:40 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
   
+1 for release
   
I ran Robert's Donkin's RAT program on the release, and it 
reported a few anomalies:
   
No license:
openjpa-project-0.9.7-incubating-source/CHANGES.txt
ok: No IP here
   
openjpa-project-0.9.7-incubating-source/RELEASE-NOTES.html
don't know: I'd approve it but others in the Incubator 
 PMC might 
feel otherwise.
   
openjpa-project-0.9.7-incubating-source/openjpa-integration/tck/
windows-replacefilter.properties
ok: No IP here
   
openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/
resources/org/apache/openjpa/jdbc/meta/java-keywords.rsrc
ok: No IP here
   
openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/
resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc
don't know: This is a dtd describing document type 
 schemas. It 
doesn't appear to be generated and certainly has some IP in

Re: [VOTE] publish openjpa 0.9.7-incubating release

2007-04-18 Thread Eddie O'Neil


The TCK dir only contains the bootstrap / glue to invoke the TCK
from within our build system, and not the TCK itself.


[eko] Yeah -- I noticed.  Just didn't know how paranoid folks tend to
be about this sort of stuff since TCK details seem to be kept under
wraps.


 - The binary distribution contains a new JAR file whose
 license is unclear; this is:
   binary-dist/lib/docbook-xsl-1.67.2.zip

That dependency is unnecessary -- it's needed to build the docs, but not
by the runtime.


[eko] Cool, maybe it's easier to delete than to figure out how it's
licensed.  ;)




On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote:

 - The binary distribution contains a new JAR file whose
 license is unclear; this is:
   binary-dist/lib/docbook-xsl-1.67.2.zip

That dependency is unnecessary -- it's needed to build the docs, but not
by the runtime.

-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: Eddie O'Neil [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 18, 2007 8:46 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release

 The release is looking good with two items that should be
 addressed and some nits.  :)

 Major issues:
 - Mike's GPG key is present in site/docs/KEYS but this file
 needs to be copied to
 http://incubator.apache.org/openjpa/KEYS as well.  This will
 make it easier to verify releases and matches the
 instructions on the download page.
 - The binary distribution contains a new JAR file whose
 license is unclear; this is:
   binary-dist/lib/docbook-xsl-1.67.2.zip

 Minor issues:
 - The Maven2 repo contains two directories that probably
 shouldn't be part of the release -- examples/ and tck/
 - The .rsrc files don't have licenses -- we've discussed this
 before (even in this thread!).  This isn't a big deal, just
 expect the iPMC to bring it up again.
 - The JPA XSDs are CDDL licensed and are included in the distribution.
  IMHO, these should be cleanroom'ed so that the question just
 goes away.  Like the .rsrc files, this has come up before and
 not been an issue.
 - The .zip distribution contains .asc files for the .md5 and
 .sha1 files, which are unnecessary.
 - The source distribution contains a derby.log file at:
   source-dist/openjpa-persistence-jdbc/derby.log

   Comments welcome, but let's work on addressing the first two.

 Eddie



 On 4/17/07, Kevin Sutter [EMAIL PROTECTED] wrote:
  +1 for the 0.9.7 release.
 
  On 4/16/07, Patrick Linskey [EMAIL PROTECTED] wrote:
  
openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/
resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc
don't know: This is a dtd describing document type
 schemas. It
doesn't appear to be generated and certainly has some IP in it.
  
   I think that our parser doesn't deal with comments for this type.
  
   
 openjpa-project-0.9.7-incubating-source/openjpa-persistence-jdbc/
derby.log
ok: This should be cleaned up for future releases but has no IP
  
   We should just move this to the target directory.
  
   I'm anxiously awaiting the day that Apache decides that
 it really is
   sufficient to describe licensing terms at the packaging
 unit level,
   rather than the individual file level.
  
   -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: Monday, April 16, 2007 11:40 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
   
+1 for release
   
I ran Robert's Donkin's RAT program on the release, and it
reported a few anomalies:
   
No license:
openjpa-project-0.9.7-incubating-source/CHANGES.txt
ok: No IP here
   
openjpa-project-0.9.7-incubating-source/RELEASE-NOTES.html
don't know: I'd approve it but others in the

[jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.

2007-04-18 Thread Patrick Linskey (JIRA)

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

Patrick Linskey commented on OPENJPA-221:
-

It's not surprising that the OpenJPA tests storeCharsAsNumbers to be true.

I was referring to your test environment. Rather than changing the default
behavior of the DerbyDictionary in code, it seems more appropriate to use the
built-in configuration option to toggle it for your application.

It sounds like you're reluctant to do this since you don't have easy access to
modify the persistence.xml files. Happily, if you drop a file conforming to the
persistence.xml schema into META-INF/openjpa.xml, OpenJPA will load the
settings in the properties in the first PU in that file as defaults for all PUs.

What happens if you put the DBDictionary stanza that I mentioned earlier into a
META-INF/openjpa.xml file?

DerbyDictionary doesn't describe a working mapping for char fields.
---

Key: OPENJPA-221
URL: https://issues.apache.org/jira/browse/OPENJPA-221
Project: OpenJPA
Issue Type: Bug
Components: sql
Affects Versions: 0.9.7
Reporter: David Jencks
Attachments: OPENJPA-221.patch

If a class has a char field mapped to CHAR or CHAR(1) in a derby database,
the derby dictionary sets up a mapping to an integer column which doesn't
work. openjpa tries to store e.g. the string 97 for the char 'a' which
results in a truncation error.

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

RE: [VOTE] publish openjpa 0.9.7-incubating release

 [eko] Yeah -- I noticed.  Just didn't know how paranoid folks 
 tend to be about this sort of stuff since TCK details seem to 
 be kept under wraps.

None of this IP comes from the TCK itself. I don't think that the TCK
license bans people from putting IP that they create while running the
TCK into the open source.

-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: Eddie O'Neil [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 18, 2007 10:17 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
 
 The TCK dir only contains the bootstrap / glue to invoke the 
 TCK  from 
 within our build system, and not the TCK itself.
 
 [eko] Yeah -- I noticed.  Just didn't know how paranoid folks 
 tend to be about this sort of stuff since TCK details seem to 
 be kept under wraps.
 
   - The binary distribution contains a new JAR file whose 
 license is 
   unclear; this is:
 binary-dist/lib/docbook-xsl-1.67.2.zip
 
  That dependency is unnecessary -- it's needed to build the 
 docs, but 
  not by the runtime.
 
 [eko] Cool, maybe it's easier to delete than to figure out 
 how it's licensed.  ;)
 
 
 
 
 On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote:
   - The binary distribution contains a new JAR file whose 
 license is 
   unclear; this is:
 binary-dist/lib/docbook-xsl-1.67.2.zip
 
  That dependency is unnecessary -- it's needed to build the 
 docs, but 
  not by the runtime.
 
  -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: Eddie O'Neil [mailto:[EMAIL PROTECTED]
   Sent: Wednesday, April 18, 2007 8:46 AM
   To: open-jpa-dev@incubator.apache.org
   Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
  
   The release is looking good with two items that should be 
 addressed 
   and some nits.  :)
  
   Major issues:
   - Mike's GPG key is present in site/docs/KEYS but this 
 file needs to 
   be copied to http://incubator.apache.org/openjpa/KEYS as 
 well.  This 
   will make it easier to verify releases and matches the 
 instructions 
   on the download page.
   - The binary distribution contains a new JAR file whose 
 license is 
   unclear; this is:
 binary-dist/lib/docbook-xsl-1.67.2.zip
  
   Minor issues:
   - The Maven2 repo contains two directories that probably 
 shouldn't 
   be part of the release -- examples/ and tck/
   - The .rsrc files don't have licenses -- we've discussed 
 this before 
   (even in this thread!).  This isn't a big deal, just 
 expect the iPMC 
   to bring it up again.
   - The JPA XSDs are CDDL licensed and are included in the 
 distribution.
IMHO, these should be cleanroom'ed so that the question 
 just goes 
   away.  Like the .rsrc files, this has come up before and 
 not been an 
   issue.
   - The .zip distribution contains .asc files for the .md5 and
   .sha1 files, which are unnecessary.
   - The source distribution contains a derby.log file at:
 source-dist/openjpa-persistence-jdbc/derby.log
  
 Comments welcome, but let's work on addressing the first two.
  
   Eddie
  
  
  
   On 4/17/07, Kevin Sutter [EMAIL PROTECTED] wrote:
+1 for the 0.9.7 release.
   
On 4/16/07, Patrick Linskey [EMAIL PROTECTED] wrote:

  
 openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/
  
 resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc
  don't know: This is a dtd describing document type
   schemas. It
  doesn't appear to be generated and certainly has 
 some IP in it.

 I think that our parser doesn't deal with comments 
 for this type.

 
   openjpa-project-0.9.7-incubating-source/openjpa-persistence-jdbc/
  derby.log
  ok: This should be cleaned up for future releases 
 but has no 
  IP

 We should just move this to the target directory.

 I'm

RE: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

 So Essentially we need to pass this subselect flag to 
 getForUpdateClause
 method.I am not sure how would we do that without overriding 
 the method in
 DB2Dictionary or chnaging the signatures in DBDictionary 
 which would affect
 many other files

Understood. I think that this is a bit of a tough question. On the one
hand, I hate to see lots of code duplication. On the other hand, it's
annoying to have unneeded concepts in other DBDictionaries.

Personally, I think that I prefer adding the boolean to the DBDictionary
method signature, or otherwise changing the DBDictionary method
signature to pass along a select or something from which many of the
boolean values could probably be inferred, or some other
DBDictionary-level refactoring.

Does anyone else have an opinion?

-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: Ritika Maheshwari [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 18, 2007 9:57 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [jira] Commented: (OPENJPA-182) db2 update lock 
 syntax WITH isolation USE AND KEEP UPDATE LOCKS
 
 1. OK I think I will open a new issue for the bug
 2. I will redo the formatting
 3.To be able to use DBDictionary method we will have to 
 change the signature
 of the
 
 toSelect(SQLBuffer selects, JDBCFetchConfiguration 
 fetch,SQLBuffer from,
 SQLBuffer where, SQLBuffer group,SQLBuffer having, SQLBuffer
 order,*boolean*distinct,
 *boolean* forUpdate, *long* start, *long* end)
 
 to include a boolean flag subselect which will be computed in the
 
 SQLBuffer toSelect(Select sel, *boolean* 
 forUpdate,JDBCFetchConfiguration
 fetch)
 
 since we have the handle to the Select here.This needs to be 
 done only for
 DB2 because  only in case of DB2 even if forUpdate is false( 
 which is set to
 false correctly for subselects by 
 SQLBuffer.resolveSubselects())  we need to
 append a FOR READ ONLY clause except in case of subselects.In other
 databases if forUpdate is false we do not append any update 
 or FOR READ ONLY
 CLAUSE. So this situaton is unique to db2.
 
 So Essentially we need to pass this subselect flag to 
 getForUpdateClause
 method.I am not sure how would we do that without overriding 
 the method in
 DB2Dictionary or chnaging the signatures in DBDictionary 
 which would affect
 many other files
 
 
 
 
 On 4/17/07, Patrick Linskey (JIRA) [EMAIL PROTECTED] wrote:
 
 
 [
  
 https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atl
assian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1248955
8]
 
  Patrick Linskey commented on OPENJPA-182:
  -
 
  Some comments:
 
  1. I don't think that we should be doing work on resolved 
 issues. So, this
  should be re-opened, or (preferably) a new issue should be 
 opened for this
  new bug.
 
  2. The patch you attached does not use OpenJPA-style 
 formatting. We don't
  have a style guide spelled out as well as we probably 
 should, but we always
  put spaces after commas, we indent 4 spaces on continuation 
 lines, and we
  put a space between an 'if' and the open paren.
 
  3. It's a shame to have to do all this code duplication between
  DBDictionary and DB2Dictionary. To what extent can we refactor
  DBDictionary's methods to make this concept work out better for
  DB2Dictionary?
 
   db2 update lock syntax  WITH isolation USE AND KEEP UPDATE LOCKS
   --
  
   Key: OPENJPA-182
   URL: 
 https://issues.apache.org/jira/browse/OPENJPA-182
   Project: OpenJPA
Issue Type: New Feature
Components: jdbc
   Environment: db2 database driver for zOS, AS400, 
 Unix, Windows,
  Linux
  Reporter: David Wisneski
   Fix For: 0.9.7
  
   Attachments: JIRA182-subselect.patch, OPENJPA-182.patch,
  OPENJPA-182.patch, openJPA182.patch, openjpa182TestCase.jar
  
  
   A while back we changed the syntax of update locking from 
 FOR UPDATE
  OF  to  WITH RS USE AND KEEP UPDATE LOCKS.   Additional 
 changes are required
  because
   1.  if isolation=serializable is configured, then the 
 syntax should
  be  WITH RR USE AND KEEP UDPATE LOCKS
   2.  when using DB2/400 on iSeries machines, the syntax is 
 WITH RS USE
  AND KEEP EXCLUSIVE LOCKS  or WITH RR USE AND KEEP EXCLUSIVE 
 LOCKS because
  DB2/400 only supports read or exclusive

RE: [VOTE] publish openjpa 0.9.7-incubating release

 This is there because we draw in all the dependencies that we 
 don't explicitly exclude in the openjpa-project/assembly.xml, 
 and at some point, someone (probably me) added docbook-xsl as 
 a dependency so as to ensure that the docbook processing 
 phase had access to the stylesheets.

Is it possible to invert that, so that we only include certain
dependencies?

-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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On 
 Behalf Of Marc Prud'hommeaux
 Sent: Wednesday, April 18, 2007 10:23 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
 
 
 On Apr 18, 2007, at 10:11 AM, Patrick Linskey wrote:
 
  - The binary distribution contains a new JAR file whose license is 
  unclear; this is:
binary-dist/lib/docbook-xsl-1.67.2.zip
 
  That dependency is unnecessary -- it's needed to build the 
 docs, but 
  not by the runtime.
 
 This is there because we draw in all the dependencies that we 
 don't explicitly exclude in the openjpa-project/assembly.xml, 
 and at some point, someone (probably me) added docbook-xsl as 
 a dependency so as to ensure that the docbook processing 
 phase had access to the stylesheets.
 
 I've gone ahead and fixed this in the trunk by adding it to 
 the exclude list (revision 530094).
 
 
 
 
 

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] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.

2007-04-18 Thread David Jencks

I'm not understanding something, maybe someone could explain, and  
obviously the comments I suggested in DBDictionary are completely  
wrong, although I sure don't see why.


IIUC derby is a pure java db optimized for use with java and storing  
java primitive types basically using java serialization.  Why would  
openjpa want to store a char in derby as an integer?  Why are the  
current settings correct, despite not working with the obvious char  
 CHAR mapping?  I haven't found the magic setting so I can see what  
table is being created for the unit tests, but I'm pretty sure it  
isn't creating a CHAR column for the char field in the allTypes object.


I assumed the problems I ran into were a result of no one having  
tested this code path, but you appear to be saying that the current  
code is more correct than my proposal.  I'd really like to know why.


On Apr 18, 2007, at 10:18 AM, Patrick Linskey (JIRA) wrote:



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


Patrick Linskey commented on OPENJPA-221:
-

It's not surprising that the OpenJPA tests storeCharsAsNumbers to  
be true.


maybe to you :-)  I still find it extremely surprising, and can't  
imagine any reason why you'd want to do this.


I was referring to your test environment. Rather than changing the  
default behavior of the DerbyDictionary in code, it seems more  
appropriate to use the built-in configuration option to toggle it  
for your application.


It sounds like you're reluctant to do this since you don't have  
easy access to modify the persistence.xml files. Happily, if you  
drop a file conforming to the persistence.xml schema into META-INF/ 
openjpa.xml, OpenJPA will load the settings in the properties in  
the first PU in that file as defaults for all PUs.


What happens if you put the DBDictionary stanza that I mentioned  
earlier into a META-INF/openjpa.xml file?


Won't this change the behavior for all databases, not just the derby  
dictionary?  I'd prefer to


(a) understand why these settings as are they are
(b) make all the db-specific dictionaries work unmodified with all  
reasonable mappings.


thanks
david jencks





DerbyDictionary doesn't describe a working mapping for char fields.
---

Key: OPENJPA-221
URL: https://issues.apache.org/jira/browse/ 
OPENJPA-221

Project: OpenJPA
 Issue Type: Bug
 Components: sql
   Affects Versions: 0.9.7
   Reporter: David Jencks
Attachments: OPENJPA-221.patch


If a class has a char field mapped to CHAR or CHAR(1) in a derby  
database, the derby dictionary sets up a mapping to an integer  
column which doesn't work.  openjpa tries to store e.g. the string  
97 for the char 'a' which results in a truncation error.


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

Re: [VOTE] publish openjpa 0.9.7-incubating release




Good idea ... I've gone ahead and done that. It should make things a  
little easier to manage.




On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote:


This is there because we draw in all the dependencies that we
don't explicitly exclude in the openjpa-project/assembly.xml,
and at some point, someone (probably me) added docbook-xsl as
a dependency so as to ensure that the docbook processing
phase had access to the stylesheets.


Is it possible to invert that, so that we only include certain
dependencies?

-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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
Behalf Of Marc Prud'hommeaux
Sent: Wednesday, April 18, 2007 10:23 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release


On Apr 18, 2007, at 10:11 AM, Patrick Linskey wrote:


- The binary distribution contains a new JAR file whose license is
unclear; this is:
  binary-dist/lib/docbook-xsl-1.67.2.zip


That dependency is unnecessary -- it's needed to build the

docs, but

not by the runtime.


This is there because we draw in all the dependencies that we
don't explicitly exclude in the openjpa-project/assembly.xml,
and at some point, someone (probably me) added docbook-xsl as
a dependency so as to ensure that the docbook processing
phase had access to the stylesheets.

I've gone ahead and fixed this in the trunk by adding it to
the exclude list (revision 530094).







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] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.

Hi,


 IIUC derby is a pure java db optimized for use with java and 
 storing java primitive types basically using java 
 serialization.  Why would openjpa want to store a char in 
 derby as an integer? 

Because we've always done it that way. Is there a reason why we should
not be storing chars as numbers? Historically, we've seen problems with
comparisons and localization issues when storing chars as chars, which
is why we store them as ints by default. Based on the fact that you said
that the unit tests fail with Derby with that configuration change, it
sounds like there are some sorts of issues with char mappings in Derby.

Additionally, since we've always done it that way, changing would mean
backwards-compatibility problems.

 Why are the current settings correct, 
 despite not working with the obvious char  CHAR mapping? 

How do you define not working? It's my expectation that if the
application behaves as expected, then things are working. It sounds like
what you're saying is the default is not what was expected, not that
things don't work.

 I haven't found the magic setting so I can see what table is 
 being created for the unit tests

openjpa.Log: SQL=TRACE

-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: David Jencks [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 18, 2007 10:53 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [jira] Commented: (OPENJPA-221) DerbyDictionary 
 doesn't describe a working mapping for char fields.
 
 I'm not understanding something, maybe someone could explain, 
 and obviously the comments I suggested in DBDictionary are 
 completely wrong, although I sure don't see why.
 
 IIUC derby is a pure java db optimized for use with java and 
 storing java primitive types basically using java 
 serialization.  Why would openjpa want to store a char in 
 derby as an integer?  Why are the current settings correct, 
 despite not working with the obvious char  CHAR mapping?  I 
 haven't found the magic setting so I can see what table is 
 being created for the unit tests, but I'm pretty sure it 
 isn't creating a CHAR column for the char field in the 
 allTypes object.
 
 I assumed the problems I ran into were a result of no one 
 having tested this code path, but you appear to be saying 
 that the current code is more correct than my proposal.  I'd 
 really like to know why.
 
 On Apr 18, 2007, at 10:18 AM, Patrick Linskey (JIRA) wrote:
 
 
  [ https://issues.apache.org/jira/browse/OPENJPA-221? 
  page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
  tabpanel#action_12489820 ]
 
  Patrick Linskey commented on OPENJPA-221:
  -
 
  It's not surprising that the OpenJPA tests 
 storeCharsAsNumbers to be 
  true.
 
 maybe to you :-)  I still find it extremely surprising, and 
 can't imagine any reason why you'd want to do this.
 
  I was referring to your test environment. Rather than changing the 
  default behavior of the DerbyDictionary in code, it seems more 
  appropriate to use the built-in configuration option to 
 toggle it for 
  your application.
 
  It sounds like you're reluctant to do this since you don't 
 have easy 
  access to modify the persistence.xml files. Happily, if you drop a 
  file conforming to the persistence.xml schema into META-INF/ 
  openjpa.xml, OpenJPA will load the settings in the 
 properties in the 
  first PU in that file as defaults for all PUs.
 
  What happens if you put the DBDictionary stanza that I mentioned 
  earlier into a META-INF/openjpa.xml file?
 
 Won't this change the behavior for all databases, not just 
 the derby dictionary?  I'd prefer to
 
 (a) understand why these settings as are they are
 (b) make all the db-specific dictionaries work unmodified 
 with all reasonable mappings.
 
 thanks
 david jencks
 
 
 
  DerbyDictionary doesn't describe a working mapping for char fields.
  ---
 
  Key: OPENJPA-221
  URL: https://issues.apache.org/jira/browse/
  OPENJPA-221
  Project: OpenJPA
   Issue Type: Bug
   Components: sql
 Affects Versions: 0.9.7
 Reporter: David Jencks
  Attachments: OPENJPA-221.patch
 
 
  If a class has a char field mapped to CHAR or CHAR(1) in a derby 
  database, the derby dictionary sets up a mapping to an 
 integer column 
  which

Re: [VOTE] publish openjpa 0.9.7-incubating release


Thanks Marc,

How do I upload my key to http://incubator.apache.org/openjpa/KEYS ?  The
only documentation I've found indicates that I need to upload it, but not
where the key needs to go.

Before I create another release candidate (to remove the docbook jar),
should we try to address the other minor issues? Craig and Patrick have
responded to most of them, but there are a few others.

Minor issues:

- The .zip distribution contains .asc files for the .md5 and .sha1

files, which are unnecessary.



They're unnecessary, but I've been ignoring them since they aren't hurting
anything. It isn't too hard to get rid of them though. I think the gpg
plugin for maven signs the .md5 and sha1 files too (I'd have to check
though).

- The source distribution contains a derby.log file at:

 source-dist/openjpa-persistence-jdbc/derby.log



This is pretty easy to clean up, and I'll do that before I create another
release candidate.

The other issues Craig and Patrick have responded to.  If any of them can be
fixed quickly then we can include them in the new release candidate.

On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:




Good idea ... I've gone ahead and done that. It should make things a
little easier to manage.



On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote:

 This is there because we draw in all the dependencies that we
 don't explicitly exclude in the openjpa-project/assembly.xml,
 and at some point, someone (probably me) added docbook-xsl as
 a dependency so as to ensure that the docbook processing
 phase had access to the stylesheets.

 Is it possible to invert that, so that we only include certain
 dependencies?

 -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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
 Behalf Of Marc Prud'hommeaux
 Sent: Wednesday, April 18, 2007 10:23 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release


 On Apr 18, 2007, at 10:11 AM, Patrick Linskey wrote:

 - The binary distribution contains a new JAR file whose license is
 unclear; this is:
   binary-dist/lib/docbook-xsl-1.67.2.zip

 That dependency is unnecessary -- it's needed to build the
 docs, but
 not by the runtime.

 This is there because we draw in all the dependencies that we
 don't explicitly exclude in the openjpa-project/assembly.xml,
 and at some point, someone (probably me) added docbook-xsl as
 a dependency so as to ensure that the docbook processing
 phase had access to the stylesheets.

 I've gone ahead and fixed this in the trunk by adding it to
 the exclude list (revision 530094).






 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.





--
-Michael Dick

Re: [VOTE] publish openjpa 0.9.7-incubating release

2007-04-18 Thread Eddie O'Neil


Mike--

 RE the KEYS file, you can just ssh to people.apache.org and check
the KEYS file out directly into /www/incubator.apache.org/openjpa/
directory.  No uploading necessary!  :)

 To be sure -- the rest of the items are just nits which could mostly
be cleaned up just by deleting the directories / files after they're
uploaded.  I don't have strong feelings about them, so just do
whatever the community feels is best.  Certainly, it's fine to ship
them for 0.9.7.

Cheers,
Eddie



On 4/18/07, Michael Dick [EMAIL PROTECTED] wrote:

Thanks Marc,

How do I upload my key to http://incubator.apache.org/openjpa/KEYS ?  The
only documentation I've found indicates that I need to upload it, but not
where the key needs to go.

Before I create another release candidate (to remove the docbook jar),
should we try to address the other minor issues? Craig and Patrick have
responded to most of them, but there are a few others.

Minor issues:

- The .zip distribution contains .asc files for the .md5 and .sha1
 files, which are unnecessary.


They're unnecessary, but I've been ignoring them since they aren't hurting
anything. It isn't too hard to get rid of them though. I think the gpg
plugin for maven signs the .md5 and sha1 files too (I'd have to check
though).

- The source distribution contains a derby.log file at:
  source-dist/openjpa-persistence-jdbc/derby.log


This is pretty easy to clean up, and I'll do that before I create another
release candidate.

The other issues Craig and Patrick have responded to.  If any of them can be
fixed quickly then we can include them in the new release candidate.

On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:



 Good idea ... I've gone ahead and done that. It should make things a
 little easier to manage.



 On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote:

  This is there because we draw in all the dependencies that we
  don't explicitly exclude in the openjpa-project/assembly.xml,
  and at some point, someone (probably me) added docbook-xsl as
  a dependency so as to ensure that the docbook processing
  phase had access to the stylesheets.
 
  Is it possible to invert that, so that we only include certain
  dependencies?
 
  -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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
  Behalf Of Marc Prud'hommeaux
  Sent: Wednesday, April 18, 2007 10:23 AM
  To: open-jpa-dev@incubator.apache.org
  Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
 
 
  On Apr 18, 2007, at 10:11 AM, Patrick Linskey wrote:
 
  - The binary distribution contains a new JAR file whose license is
  unclear; this is:
binary-dist/lib/docbook-xsl-1.67.2.zip
 
  That dependency is unnecessary -- it's needed to build the
  docs, but
  not by the runtime.
 
  This is there because we draw in all the dependencies that we
  don't explicitly exclude in the openjpa-project/assembly.xml,
  and at some point, someone (probably me) added docbook-xsl as
  a dependency so as to ensure that the docbook processing
  phase had access to the stylesheets.
 
  I've gone ahead and fixed this in the trunk by adding it to
  the exclude list (revision 530094).
 
 
 
 
 
 
  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.




--
-Michael Dick

RE: [DISCUSS] required vs. optional dependencies

- commons-logging-1.0.4.jar (used only in 
 CommonsLogFactory when logging is configured to use commons)

I think that we should leave this out altogether. Anyone who wants to
use commons logging will presumably have commons logging.

- commons-pool-1.3.jar (used only in 
 TCPRemoteCommitProvider for distributed data caching)

We should keep this, since it is required for one of our built-in
options, although it's unfortunate to have the extra dependency for just
one bit of code.

- geronimo-jms_1.1_spec-1.0.1.jar (used only in 
 JMSRemoteCommitProvider for distributed data caching)

We should leave this out, since anyone who uses the JMS RCP will need to
have a JMS server, and will therefore presumably have JMS jars.

- derby-10.2.2.0.jar (provided only as a convenience for 
 getting started with the examples quickly)

I think that we should keep this.

 My question: should we differentiate between the required 
 libraries and the optional ones (perhaps by putting them in 
 an /optional/ directory or something)? Does anyone have 
 experience with how this is done with other Apache projects?

I think that we should make the changes I outlined above, and we should
not create an /optional/ for other 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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On 
 Behalf Of Marc Prud'hommeaux
 Sent: Wednesday, April 18, 2007 11:31 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: [DISCUSS] required vs. optional dependencies
 
 
 Currently with OpenJPA, we ship with the following jars in the lib/
 directory:
 
* commons-lang-2.1.jar
* commons-collections-3.2.jar
* geronimo-jta_1.0.1B_spec-1.0.1.jar
* geronimo-jpa_3.0_spec-1.0.jar
* geronimo-j2ee-connector_1.5_spec-1.0.1.jar
* serp-1.11.0.jar
- commons-logging-1.0.4.jar (used only in 
 CommonsLogFactory when logging is configured to use commons)
- commons-pool-1.3.jar (used only in 
 TCPRemoteCommitProvider for distributed data caching)
- geronimo-jms_1.1_spec-1.0.1.jar (used only in 
 JMSRemoteCommitProvider for distributed data caching)
- derby-10.2.2.0.jar (provided only as a convenience for 
 getting started with the examples quickly)
 
 The jars marked with stars (*) are the only ones that are 
 actually required for OpenJPA to function in the common cases 
 (the examples included in the distribution all run if you 
 have just the starred libraries + derby).
 
 My question: should we differentiate between the required 
 libraries and the optional ones (perhaps by putting them in 
 an /optional/ directory or something)? Does anyone have 
 experience with how this is done with other Apache projects?
 
 
 

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: [VOTE] publish openjpa 0.9.7-incubating release


Michael-

On Apr 18, 2007, at 11:35 AM, Michael Dick wrote:


Thanks Marc,

How do I upload my key to http://incubator.apache.org/openjpa/ 
KEYS ?  The
only documentation I've found indicates that I need to upload it,  
but not

where the key needs to go.



As Eddie mentioned, you should be able to ssh into people.apache.org  
and edit /www/incubator.apache.org/openjpa/KEYS directly (and then  
check it in). After that is done, there is a delay (maybe around an  
hour) before it will be mirrored and start showing up at http:// 
incubator.apache.org/openjpa/KEYS


You could also check out https://svn.apache.org/repos/asf/incubator/ 
openjpa/site/docs/ locally, edit the KEYS file, check it in, and then  
ssh to people.apache.org and 'svn up KEYS', but it's probably easier  
to just do it on people.apache.org.





- The source distribution contains a derby.log file at:

 source-dist/openjpa-persistence-jdbc/derby.log



This is pretty easy to clean up, and I'll do that before I create  
another

release candidate.


I think I noticed a commit from Patrick that fixes this for the  
future (I believe he set a derby property to tell it to put the log  
in target/).

RE: [VOTE] publish openjpa 0.9.7-incubating release

  - The source distribution contains a derby.log file at:
   source-dist/openjpa-persistence-jdbc/derby.log
 
 
  This is pretty easy to clean up, and I'll do that before I create 
  another release candidate.
 
 I think I noticed a commit from Patrick that fixes this for 
 the future (I believe he set a derby property to tell it to 
 put the log in target/).

Actually, it was Mike that made the change. 

-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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On 
 Behalf Of Marc Prud'hommeaux
 Sent: Wednesday, April 18, 2007 11:49 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
 
 Michael-
 
 On Apr 18, 2007, at 11:35 AM, Michael Dick wrote:
 
  Thanks Marc,
 
  How do I upload my key to http://incubator.apache.org/openjpa/
  KEYS ?  The
  only documentation I've found indicates that I need to 
 upload it, but 
  not where the key needs to go.
 
 
 As Eddie mentioned, you should be able to ssh into 
 people.apache.org and edit 
 /www/incubator.apache.org/openjpa/KEYS directly (and then 
 check it in). After that is done, there is a delay (maybe around an
 hour) before it will be mirrored and start showing up at 
 http:// incubator.apache.org/openjpa/KEYS
 
 You could also check out https://svn.apache.org/repos/asf/incubator/
 openjpa/site/docs/ locally, edit the KEYS file, check it in, 
 and then ssh to people.apache.org and 'svn up KEYS', but it's 
 probably easier to just do it on people.apache.org.
 
 
 
  - The source distribution contains a derby.log file at:
   source-dist/openjpa-persistence-jdbc/derby.log
 
 
  This is pretty easy to clean up, and I'll do that before I create 
  another release candidate.
 
 I think I noticed a commit from Patrick that fixes this for 
 the future (I believe he set a derby property to tell it to 
 put the log in target/).
 
 
 
 

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.

Spurious warnings during runtime schema update

2007-04-18 Thread Jonathan Feinberg

When SychronizeMappings is set to buildSchema, as it always is for me (in 
head-down development mode), every run of unit tests or app server is prefaced 
by a large collection of spurious warnings. A specimen:
3635  myproj   WARN   [http-8080-Processor24] openjpa.jdbc.Schema - Existing 
column id on table public.share is incompatible with the same column in the 
given schema definition. Existing column:
Full Name: share.id
Type: char
Size: 32
Default: null
Not Null: true
Given column:
Full Name: Share.id
Type: varchar
Size: 255
Default: null
Not Null: true
Now, the existing column was, of course, originally created (correctly) as a 
char(32) by the same schema update routine, thanks to the following annotation 
on the field in question:
 @Id
 @GeneratedValue(generator = uuid-hex)
 @Column(columnDefinition = char(32))
 public String getId()
 {
  return id;
 }
Why does the schema sync complain? I have tried asking the sync to read schema, 
a la
property name=openjpa.jdbc.SynchronizeMappings
value=buildSchema(ReadSchema=true) /
but it made no difference.

Thanks,
--

Re: [VOTE] publish openjpa 0.9.7-incubating release



On Apr 18, 2007, at 10:19 AM, Patrick Linskey wrote:


[eko] Yeah -- I noticed.  Just didn't know how paranoid folks
tend to be about this sort of stuff since TCK details seem to
be kept under wraps.


None of this IP comes from the TCK itself. I don't think that the TCK
license bans people from putting IP that they create while running the
TCK into the open source.


Right. The only thing that we need to worry about is leaking TCK IP.  
Which this project does not.


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: Eddie O'Neil [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 10:17 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release


The TCK dir only contains the bootstrap / glue to invoke the

TCK  from

within our build system, and not the TCK itself.


[eko] Yeah -- I noticed.  Just didn't know how paranoid folks
tend to be about this sort of stuff since TCK details seem to
be kept under wraps.


- The binary distribution contains a new JAR file whose

license is

unclear; this is:
  binary-dist/lib/docbook-xsl-1.67.2.zip


That dependency is unnecessary -- it's needed to build the

docs, but

not by the runtime.


[eko] Cool, maybe it's easier to delete than to figure out
how it's licensed.  ;)




On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote:

- The binary distribution contains a new JAR file whose

license is

unclear; this is:
  binary-dist/lib/docbook-xsl-1.67.2.zip


That dependency is unnecessary -- it's needed to build the

docs, but

not by the runtime.

-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: Eddie O'Neil [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 8:46 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release

The release is looking good with two items that should be

addressed

and some nits.  :)

Major issues:
- Mike's GPG key is present in site/docs/KEYS but this

file needs to

be copied to http://incubator.apache.org/openjpa/KEYS as

well.  This

will make it easier to verify releases and matches the

instructions

on the download page.
- The binary distribution contains a new JAR file whose

license is

unclear; this is:
  binary-dist/lib/docbook-xsl-1.67.2.zip

Minor issues:
- The Maven2 repo contains two directories that probably

shouldn't

be part of the release -- examples/ and tck/
- The .rsrc files don't have licenses -- we've discussed

this before

(even in this thread!).  This isn't a big deal, just

expect the iPMC

to bring it up again.
- The JPA XSDs are CDDL licensed and are included in the

distribution.

 IMHO, these should be cleanroom'ed so that the question

just goes

away.  Like the .rsrc files, this has come up before and

not been an

issue.
- The .zip distribution contains .asc files for the .md5 and
.sha1 files, which are unnecessary.
- The source distribution contains a derby.log file at:
  source-dist/openjpa-persistence-jdbc/derby.log

  Comments welcome, but let's work on addressing the first two.

Eddie



On 4/17/07, Kevin Sutter [EMAIL PROTECTED] wrote:

+1 for the 0.9.7 release.

On 4/16/07, Patrick Linskey [EMAIL PROTECTED] wrote:





openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/



resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc

don't know: This is a dtd describing document type

schemas. It

doesn't appear to be generated and certainly has

some IP in it.


I think that our parser doesn't deal with comments

for this type.





openjpa-project-0.9.7-incubating-source/openjpa-persistence-jdbc/

derby.log
ok: This should be cleaned up for future releases

but has no

IP


We should just move this to the target directory.

I'm anxiously awaiting the day that Apache decides that

it really is

sufficient to describe licensing terms at the

Re: [VOTE] publish openjpa 0.9.7-incubating release


For the record, I'm still

+1 for release.

But if you want to cut another to fix the minor items that have been  
surfaced, it's ok with me.


Craig

On Apr 18, 2007, at 11:42 AM, Eddie O'Neil wrote:


Mike--

 RE the KEYS file, you can just ssh to people.apache.org and check
the KEYS file out directly into /www/incubator.apache.org/openjpa/
directory.  No uploading necessary!  :)

 To be sure -- the rest of the items are just nits which could mostly
be cleaned up just by deleting the directories / files after they're
uploaded.  I don't have strong feelings about them, so just do
whatever the community feels is best.  Certainly, it's fine to ship
them for 0.9.7.

Cheers,
Eddie



On 4/18/07, Michael Dick [EMAIL PROTECTED] wrote:

Thanks Marc,

How do I upload my key to http://incubator.apache.org/openjpa/ 
KEYS ?  The
only documentation I've found indicates that I need to upload it,  
but not

where the key needs to go.

Before I create another release candidate (to remove the docbook  
jar),
should we try to address the other minor issues? Craig and Patrick  
have

responded to most of them, but there are a few others.

Minor issues:

- The .zip distribution contains .asc files for the .md5 and .sha1
 files, which are unnecessary.


They're unnecessary, but I've been ignoring them since they aren't  
hurting
anything. It isn't too hard to get rid of them though. I think the  
gpg

plugin for maven signs the .md5 and sha1 files too (I'd have to check
though).

- The source distribution contains a derby.log file at:
  source-dist/openjpa-persistence-jdbc/derby.log


This is pretty easy to clean up, and I'll do that before I create  
another

release candidate.

The other issues Craig and Patrick have responded to.  If any of  
them can be

fixed quickly then we can include them in the new release candidate.

On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:



 Good idea ... I've gone ahead and done that. It should make  
things a

 little easier to manage.



 On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote:

  This is there because we draw in all the dependencies that we
  don't explicitly exclude in the openjpa-project/assembly.xml,
  and at some point, someone (probably me) added docbook-xsl as
  a dependency so as to ensure that the docbook processing
  phase had access to the stylesheets.
 
  Is it possible to invert that, so that we only include certain
  dependencies?
 
  -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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
  Behalf Of Marc Prud'hommeaux
  Sent: Wednesday, April 18, 2007 10:23 AM
  To: open-jpa-dev@incubator.apache.org
  Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
 
 
  On Apr 18, 2007, at 10:11 AM, Patrick Linskey wrote:
 
  - The binary distribution contains a new JAR file whose  
license is

  unclear; this is:
binary-dist/lib/docbook-xsl-1.67.2.zip
 
  That dependency is unnecessary -- it's needed to build the
  docs, but
  not by the runtime.
 
  This is there because we draw in all the dependencies that we
  don't explicitly exclude in the openjpa-project/assembly.xml,
  and at some point, someone (probably me) added docbook-xsl as
  a dependency so as to ensure that the docbook processing
  phase had access to the stylesheets.
 
  I've gone ahead and fixed this in the trunk by adding it to
  the exclude list (revision 530094).
 
 
 
 
 
 
  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.





--
-Michael Dick



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

Any way to index multiple columns?

2007-04-18 Thread Jonathan Feinberg

Is there any way to cause the OpenJPA schema builder to emit an index across 
multiple columns? My attempt,
 @Column(columnDefinition = bytea)
 @Index(name = i_owner_md5, columnNames = { owner_id, md5 })
 public byte[] getMd5()
 {
  return md5;
 }
is silently misinterpreted, in that only the annotated field (md5) gets indexed.

Thanks,
--

Re: [VOTE] publish openjpa 0.9.7-incubating release


I'd rather not cut another release, but I think we do need to resolve the
issue with the docbook jar. If we can live with the extra jar then the vote
can proceed.

If I go back and remove the jar, republish etc. I'm assuming we'll have to
restart the clock on the vote, correct me if I'm wrong in this regard.

On 4/18/07, Craig L Russell [EMAIL PROTECTED] wrote:


For the record, I'm still

+1 for release.

But if you want to cut another to fix the minor items that have been
surfaced, it's ok with me.

Craig

On Apr 18, 2007, at 11:42 AM, Eddie O'Neil wrote:

 Mike--

  RE the KEYS file, you can just ssh to people.apache.org and check
 the KEYS file out directly into /www/incubator.apache.org/openjpa/
 directory.  No uploading necessary!  :)

  To be sure -- the rest of the items are just nits which could mostly
 be cleaned up just by deleting the directories / files after they're
 uploaded.  I don't have strong feelings about them, so just do
 whatever the community feels is best.  Certainly, it's fine to ship
 them for 0.9.7.

 Cheers,
 Eddie



 On 4/18/07, Michael Dick [EMAIL PROTECTED] wrote:
 Thanks Marc,

 How do I upload my key to http://incubator.apache.org/openjpa/
 KEYS ?  The
 only documentation I've found indicates that I need to upload it,
 but not
 where the key needs to go.

 Before I create another release candidate (to remove the docbook
 jar),
 should we try to address the other minor issues? Craig and Patrick
 have
 responded to most of them, but there are a few others.

 Minor issues:

 - The .zip distribution contains .asc files for the .md5 and .sha1
  files, which are unnecessary.


 They're unnecessary, but I've been ignoring them since they aren't
 hurting
 anything. It isn't too hard to get rid of them though. I think the
 gpg
 plugin for maven signs the .md5 and sha1 files too (I'd have to check
 though).

 - The source distribution contains a derby.log file at:
   source-dist/openjpa-persistence-jdbc/derby.log


 This is pretty easy to clean up, and I'll do that before I create
 another
 release candidate.

 The other issues Craig and Patrick have responded to.  If any of
 them can be
 fixed quickly then we can include them in the new release candidate.

 On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
 
 
 
  Good idea ... I've gone ahead and done that. It should make
 things a
  little easier to manage.
 
 
 
  On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote:
 
   This is there because we draw in all the dependencies that we
   don't explicitly exclude in the openjpa-project/assembly.xml,
   and at some point, someone (probably me) added docbook-xsl as
   a dependency so as to ensure that the docbook processing
   phase had access to the stylesheets.
  
   Is it possible to invert that, so that we only include certain
   dependencies?
  
   -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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
   Behalf Of Marc Prud'hommeaux
   Sent: Wednesday, April 18, 2007 10:23 AM
   To: open-jpa-dev@incubator.apache.org
   Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
  
  
   On Apr 18, 2007, at 10:11 AM, Patrick Linskey wrote:
  
   - The binary distribution contains a new JAR file whose
 license is
   unclear; this is:
 binary-dist/lib/docbook-xsl-1.67.2.zip
  
   That dependency is unnecessary -- it's needed to build the
   docs, but
   not by the runtime.
  
   This is there because we draw in all the dependencies that we
   don't explicitly exclude in the openjpa-project/assembly.xml,
   and at some point, someone (probably me) added docbook-xsl as
   a dependency so as to ensure that the docbook processing
   phase had access to the stylesheets.
  
   I've gone ahead and fixed this in the trunk by adding it to
   the exclude list (revision 530094).
  
  
  
  
  
  
   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.
 
 


 --
 -Michael Dick


Craig Russell

RE: [VOTE] publish openjpa 0.9.7-incubating release

... but we can run the incubator and the openjpa votes in parallel,
right? If we're pretty sure that with the removal of that jar, we'll be
happy, then we could rebuild and start off those two votes at the same
time.

-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, April 18, 2007 12:30 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release
 
 Hi Mike,
 
 On Apr 18, 2007, at 12:27 PM, Michael Dick wrote:
 
  I'd rather not cut another release, but I think we do need 
 to resolve 
  the issue with the docbook jar. If we can live with the 
 extra jar then 
  the vote can proceed.
 
  If I go back and remove the jar, republish etc. I'm assuming we'll 
  have to restart the clock on the vote, correct me if I'm 
 wrong in this 
  regard.
 
 Yes, changing the bits restarts the clock.
 
 Craig
 
  On 4/18/07, Craig L Russell [EMAIL PROTECTED] wrote:
 
  For the record, I'm still
 
  +1 for release.
 
  But if you want to cut another to fix the minor items that 
 have been 
  surfaced, it's ok with me.
 
  Craig
 
  On Apr 18, 2007, at 11:42 AM, Eddie O'Neil wrote:
 
   Mike--
  
RE the KEYS file, you can just ssh to people.apache.org 
 and check 
   the KEYS file out directly into 
 /www/incubator.apache.org/openjpa/
   directory.  No uploading necessary!  :)
  
To be sure -- the rest of the items are just nits which could
  mostly
   be cleaned up just by deleting the directories / files after
  they're
   uploaded.  I don't have strong feelings about them, so just do 
   whatever the community feels is best.  Certainly, it's 
 fine to ship 
   them for 0.9.7.
  
   Cheers,
   Eddie
  
  
  
   On 4/18/07, Michael Dick [EMAIL PROTECTED] wrote:
   Thanks Marc,
  
   How do I upload my key to http://incubator.apache.org/openjpa/
   KEYS ?  The
   only documentation I've found indicates that I need to 
 upload it, 
   but not where the key needs to go.
  
   Before I create another release candidate (to remove 
 the docbook 
   jar), should we try to address the other minor issues? 
 Craig and 
   Patrick have responded to most of them, but there are a few 
   others.
  
   Minor issues:
  
   - The .zip distribution contains .asc files for the 
 .md5 and .sha1
files, which are unnecessary.
  
  
   They're unnecessary, but I've been ignoring them since 
 they aren't 
   hurting anything. It isn't too hard to get rid of them 
 though. I 
   think the gpg plugin for maven signs the .md5 and sha1 
 files too 
   (I'd have to
  check
   though).
  
   - The source distribution contains a derby.log file at:
 source-dist/openjpa-persistence-jdbc/derby.log
  
  
   This is pretty easy to clean up, and I'll do that 
 before I create 
   another release candidate.
  
   The other issues Craig and Patrick have responded to.  
 If any of 
   them can be fixed quickly then we can include them in the new 
   release
  candidate.
  
   On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
   
   
   
Good idea ... I've gone ahead and done that. It should make
   things a
little easier to manage.
   
   
   
On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote:
   
 This is there because we draw in all the 
 dependencies that we 
 don't explicitly exclude in the 
 openjpa-project/assembly.xml, 
 and at some point, someone (probably me) added 
 docbook-xsl as 
 a dependency so as to ensure that the docbook processing 
 phase had access to the stylesheets.

 Is it possible to invert that, so that we only 
 include certain 
 dependencies?

 -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: Marc Prud'hommeaux

RE: Named query created in error

What error do you get?

I expect that it's joining extra data because your one-to-ones and
many-to-ones are marked up to use eager fetching. Note that eager
fetching is the default for one-to-one and many-to-one relations, so if
you have not marked up these relations as lazy, then they're implicitly
eager.

-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: Phill Moran [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 18, 2007 12:23 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Named query created in error
 
 Anyone seen this before?
 
 I have the following named query
 
 @NamedQuery(name = PersonFXStoreAndLogin, query = SELECT p 
 FROM Person p WHERE UPPER(p.store.name) = :storeName and 
 UPPER(p.loginName) = :loginName ORDER BY p.lastName, p.firstName)
 
 That generated the following SQL statement
 
 SELECT t0.id, t0.lastUpdated, t0.active, t0.activeFrom, 
 t0.activeUntil, t0.created, t0.displayName, t0.firstName, 
 t0.lastLogin, t0.lastName, t0.locale, t0.loginName, 
 t0.middleName, t2.id, t2.lastUpdated, t2.description, t3.id, 
 t3.lastUpdated, t3.description, t2.value, t4.id, 
 t4.lastUpdated, t4.description, t4.categoryTypeFK, t4.value, 
 t1.id, t1.lastUpdated, t1.created, t1.description, 
 t1.displayName, t1.name, t5.id, t5.lastUpdated, 
 t5.description, t5.categoryTypeFK, t5.value, t0.title, 
 t0.visible FROM bidspec.person t0 INNER JOIN 
 bidspec.manufacturer t1 ON t0.manufacturerFK = t1.id LEFT 
 OUTER JOIN bidspec.category t2 ON t0.roleFK = t2.id LEFT 
 OUTER JOIN bidspec.category t4 ON t0.salutationFK = t4.id 
 LEFT OUTER JOIN bidspec.category t5 ON t1.typeFK = t5.id LEFT 
 OUTER JOIN bidspec.categorytype t3 ON t2.categoryTypeFK = t3.id WHERE
 (UPPER(t1.name) = ? AND UPPER(t0.loginName) = ?) ORDER BY 
 t0.lastName ASC, t0.firstName ASC [params=(String) BIDSPEC, 
 (String) PMORAN]
 
 Notice how it is grabbing columns from joined tables. This 
 means it cannot build the object (Person) I am expecting to 
 get returned and throws an exception. Cool huh?
 
 My guess is that I should not be drilling down with the 
 UPPER(p.store.name)
 which is a field within one of these joined tables (t1).
 
 Thoughts?
 
 Phill
 
 

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: [VOTE] publish openjpa 0.9.7-incubating release


On Apr 18, 2007, at 12:53 PM, Patrick Linskey wrote:


... but we can run the incubator and the openjpa votes in parallel,
right? If we're pretty sure that with the removal of that jar,  
we'll be

happy, then we could rebuild and start off those two votes at the same
time.


Yes, this is true.

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: Wednesday, April 18, 2007 12:30 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release

Hi Mike,

On Apr 18, 2007, at 12:27 PM, Michael Dick wrote:


I'd rather not cut another release, but I think we do need

to resolve

the issue with the docbook jar. If we can live with the

extra jar then

the vote can proceed.

If I go back and remove the jar, republish etc. I'm assuming we'll
have to restart the clock on the vote, correct me if I'm

wrong in this

regard.


Yes, changing the bits restarts the clock.

Craig


On 4/18/07, Craig L Russell [EMAIL PROTECTED] wrote:


For the record, I'm still

+1 for release.

But if you want to cut another to fix the minor items that

have been

surfaced, it's ok with me.

Craig

On Apr 18, 2007, at 11:42 AM, Eddie O'Neil wrote:


Mike--

 RE the KEYS file, you can just ssh to people.apache.org

and check

the KEYS file out directly into

/www/incubator.apache.org/openjpa/

directory.  No uploading necessary!  :)

 To be sure -- the rest of the items are just nits which could

mostly

be cleaned up just by deleting the directories / files after

they're

uploaded.  I don't have strong feelings about them, so just do
whatever the community feels is best.  Certainly, it's

fine to ship

them for 0.9.7.

Cheers,
Eddie



On 4/18/07, Michael Dick [EMAIL PROTECTED] wrote:

Thanks Marc,

How do I upload my key to http://incubator.apache.org/openjpa/
KEYS ?  The
only documentation I've found indicates that I need to

upload it,

but not where the key needs to go.

Before I create another release candidate (to remove

the docbook

jar), should we try to address the other minor issues?

Craig and

Patrick have responded to most of them, but there are a few
others.

Minor issues:

- The .zip distribution contains .asc files for the

.md5 and .sha1

files, which are unnecessary.



They're unnecessary, but I've been ignoring them since

they aren't

hurting anything. It isn't too hard to get rid of them

though. I

think the gpg plugin for maven signs the .md5 and sha1

files too

(I'd have to

check

though).

- The source distribution contains a derby.log file at:

 source-dist/openjpa-persistence-jdbc/derby.log



This is pretty easy to clean up, and I'll do that

before I create

another release candidate.

The other issues Craig and Patrick have responded to.

If any of

them can be fixed quickly then we can include them in the new
release

candidate.


On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:




Good idea ... I've gone ahead and done that. It should make

things a

little easier to manage.



On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote:


This is there because we draw in all the

dependencies that we

don't explicitly exclude in the

openjpa-project/assembly.xml,

and at some point, someone (probably me) added

docbook-xsl as

a dependency so as to ensure that the docbook processing
phase had access to the stylesheets.


Is it possible to invert that, so that we only

include certain

dependencies?

-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: Marc Prud'hommeaux

[mailto:[EMAIL PROTECTED] On

Behalf Of Marc Prud'hommeaux
Sent: Wednesday, April 18, 2007 10:23 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [VOTE] publish openjpa

0.9.7-incubating release



On Apr 18, 2007, at 10:11 AM, Patrick Linskey wrote:


- The binary distribution contains a new

Re: [VOTE] publish openjpa 0.9.7-incubating release


Michael-

On Apr 18, 2007, at 12:27 PM, Michael Dick wrote:

I'd rather not cut another release, but I think we do need to  
resolve the
issue with the docbook jar. If we can live with the extra jar then  
the vote

can proceed.


Personally, I think it is sufficiently ugly to release with the  
docbook jar to justify starting another release.


However, if others disagree, I'll happily accede to the majority. For  
now, my vote changes to +0.

Re: Any way to index multiple columns?


Jonathan-

It looks like we indeed do ignore the columnNames field of the index.  
This is a bug, and I've entered it at:


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

I don't think there is a workaround, unless the index is unique, in  
which case you can use the JPA standard  
javax.persistence.UniqueConstraint annotation on the @Table  
annotation (which allows you to specify multiple columns, and which  
we appear to respect).




On Apr 18, 2007, at 11:56 AM, Jonathan Feinberg wrote:

Is there any way to cause the OpenJPA schema builder to emit an  
index across multiple columns? My attempt,

 @Column(columnDefinition = bytea)
 @Index(name = i_owner_md5, columnNames = { owner_id, md5 })
 public byte[] getMd5()
 {
  return md5;
 }
is silently misinterpreted, in that only the annotated field (md5)  
gets indexed.


Thanks,
--

[jira] Assigned: (OPENJPA-222) FOR READ ONLY clause getting generated for subselects

2007-04-18 Thread Michael Dick (JIRA)


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

Michael Dick reassigned OPENJPA-222:


Assignee: David Wisneski

 FOR READ ONLY clause getting generated for subselects
 -

 Key: OPENJPA-222
 URL: https://issues.apache.org/jira/browse/OPENJPA-222
 Project: OpenJPA
  Issue Type: Bug
  Components: jpa
Affects Versions: 0.9.7
Reporter: Ritika Maheshwari
 Assigned To: David Wisneski
 Attachments: JIRA182-subselect.patch


 FOR READ ONLY clause is generated for subselects in DB2. which throws a DB2 
 Exception

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

Re: [DISCUSS] required vs. optional dependencies


In general I agree with Patrick. I'm +0 regarding including Derby, it's nice
for the examples, but it just doesn't seem right to include a preferred
database . No logical reason, just personal preference.


On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote:


- commons-logging-1.0.4.jar (used only in
 CommonsLogFactory when logging is configured to use commons)

I think that we should leave this out altogether. Anyone who wants to
use commons logging will presumably have commons logging.

- commons-pool-1.3.jar (used only in
 TCPRemoteCommitProvider for distributed data caching)

We should keep this, since it is required for one of our built-in
options, although it's unfortunate to have the extra dependency for just
one bit of code.

- geronimo-jms_1.1_spec-1.0.1.jar (used only in
 JMSRemoteCommitProvider for distributed data caching)

We should leave this out, since anyone who uses the JMS RCP will need to
have a JMS server, and will therefore presumably have JMS jars.

- derby-10.2.2.0.jar (provided only as a convenience for
 getting started with the examples quickly)

I think that we should keep this.

 My question: should we differentiate between the required
 libraries and the optional ones (perhaps by putting them in
 an /optional/ directory or something)? Does anyone have
 experience with how this is done with other Apache projects?

I think that we should make the changes I outlined above, and we should
not create an /optional/ for other 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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
 Behalf Of Marc Prud'hommeaux
 Sent: Wednesday, April 18, 2007 11:31 AM
 To: open-jpa-dev@incubator.apache.org
 Subject: [DISCUSS] required vs. optional dependencies


 Currently with OpenJPA, we ship with the following jars in the lib/
 directory:

* commons-lang-2.1.jar
* commons-collections-3.2.jar
* geronimo-jta_1.0.1B_spec-1.0.1.jar
* geronimo-jpa_3.0_spec-1.0.jar
* geronimo-j2ee-connector_1.5_spec-1.0.1.jar
* serp-1.11.0.jar
- commons-logging-1.0.4.jar (used only in
 CommonsLogFactory when logging is configured to use commons)
- commons-pool-1.3.jar (used only in
 TCPRemoteCommitProvider for distributed data caching)
- geronimo-jms_1.1_spec-1.0.1.jar (used only in
 JMSRemoteCommitProvider for distributed data caching)
- derby-10.2.2.0.jar (provided only as a convenience for
 getting started with the examples quickly)

 The jars marked with stars (*) are the only ones that are
 actually required for OpenJPA to function in the common cases
 (the examples included in the distribution all run if you
 have just the starred libraries + derby).

 My question: should we differentiate between the required
 libraries and the optional ones (perhaps by putting them in
 an /optional/ directory or something)? Does anyone have
 experience with how this is done with other Apache projects?




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.





--
-Michael Dick

Re: Named query created in error

2007-04-18 Thread Jacek Laskowski


On 4/18/07, Phill Moran [EMAIL PROTECTED] wrote:


The exception I get is null pointer from this line:

ListPerson results = (ListPerson) q.getResultList();


Could you show the query creation and the stack trace you're getting?

Jacek

--
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: [jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.

2007-04-18 Thread David Jencks



On Apr 18, 2007, at 11:12 AM, Patrick Linskey wrote:


Hi,



IIUC derby is a pure java db optimized for use with java and
storing java primitive types basically using java
serialization.  Why would openjpa want to store a char in
derby as an integer?


Because we've always done it that way. Is there a reason why we  
should
not be storing chars as numbers? Historically, we've seen problems  
with

comparisons and localization issues when storing chars as chars, which
is why we store them as ints by default.


Does that mean you store Strings as arrays of integers by default for  
the same reason?  Why is this different?



Based on the fact that you said
that the unit tests fail with Derby with that configuration change, it
sounds like there are some sorts of issues with char mappings in  
Derby.


The unit tests fail with only the storeCharsAsIntegers=false because  
the sql for creating the table is invalid.  They succeed with the  
additional patch to create a CHAR(1) column instead of CHAR(255) for  
a char field.  I'm happy to discuss if creating a  CHAR(255) column  
to store a char field is reasonable :-)


Additionally, since we've always done it that way, changing would mean
backwards-compatibility problems.


There aren't any non-incubator openjpa releases yet, so I don't see  
the problem.  I'd also expect that for preexisting tables either an  
INTEGER or CHAR column would work.





Why are the current settings correct,
despite not working with the obvious char  CHAR mapping?


How do you define not working? It's my expectation that if the
application behaves as expected, then things are working. It sounds  
like

what you're saying is the default is not what was expected, not that
things don't work.


I expect that if I have a char field in an object and a preexisting  
table with a CHAR column openjpa will figure out some way to get a  
char from the field to the column and back again without any  
additional configuration, for all databases.  Admittedly my proposed  
fix only does this for derby, and by changing the default mapping for  
chars for derby.


I additionally expect that if openjpa creates a schema for me for a  
database with default utf support it will map a char field to a CHAR  
column.  I wouldn't necessarily expect this for a database that by  
default doesn't have utf columns.





I haven't found the magic setting so I can see what table is
being created for the unit tests


openjpa.Log: SQL=TRACE


Where would I put this so I could see what the unit tests were doing?

I think there are 2 issues here:

1. should openjpa be able to use a preexisting CHAR column for  
storing a char, no matter what the storeCharsAsInteger setting is?

2. should the settings for derby be storeCharsAsInteger = false or true?

(1) is a lot more important, but changing the answer to (2) is easier  
and solves my immediate problem.


thanks
david jencks



-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: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 10:53 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [jira] Commented: (OPENJPA-221) DerbyDictionary
doesn't describe a working mapping for char fields.

I'm not understanding something, maybe someone could explain,
and obviously the comments I suggested in DBDictionary are
completely wrong, although I sure don't see why.

IIUC derby is a pure java db optimized for use with java and
storing java primitive types basically using java
serialization.  Why would openjpa want to store a char in
derby as an integer?  Why are the current settings correct,
despite not working with the obvious char  CHAR mapping?  I
haven't found the magic setting so I can see what table is
being created for the unit tests, but I'm pretty sure it
isn't creating a CHAR column for the char field in the
allTypes object.

I assumed the problems I ran into were a result of no one
having tested this code path, but you appear to be saying
that the current code is more correct than my proposal.  I'd
really like to know why.

On Apr 18, 2007, at 10:18 AM, Patrick Linskey (JIRA) wrote:



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

Patrick Linskey commented on OPENJPA-221:
-

It's not surprising that the OpenJPA tests

storeCharsAsNumbers

RE: Named query created in error

2007-04-18 Thread Phill Moran

Here it is:

[2007-04-18 18:37:07,937] INFO  ca.BidSpec.testing.emall.UserFactoryTest Began
transaction (1): transaction manager
[EMAIL PROTECTED]; default rollback =
true 
25547  WARN   [main] openjpa.MetaData - Found duplicate query
PersonFXLastFirst in class ca.BidSpec.emall.user.Person.  Ignoring.
33360  TRACE  [main] openjpa.jdbc.SQL - t 19399109, conn 28442012 executing
prepstmnt 23861335 SELECT t0.id, t0.lastUpdated, t0.active, t0.activeFrom,
t0.activeUntil, t0.created, t0.displayName, t0.firstName, t0.lastLogin,
t0.lastName, t0.locale, t0.loginName, t0.middleName, t2.id, t2.lastUpdated,
t2.description, t3.id, t3.lastUpdated, t3.description, t2.value, t4.id,
t4.lastUpdated, t4.description, t4.categoryTypeFK, t4.value, t5.id,
t5.lastUpdated, t5.created, t5.description, t5.displayName, t5.name, t6.id,
t6.lastUpdated, t6.description, t6.categoryTypeFK, t6.value, t0.title,
t0.visible FROM bidspec.person t0 INNER JOIN bidspec.manufacturer t1 ON
t0.manufacturerFK = t1.id LEFT OUTER JOIN bidspec.category t2 ON t0.roleFK =
t2.id LEFT OUTER JOIN bidspec.category t4 ON t0.salutationFK = t4.id LEFT OUTER
JOIN bidspec.manufacturer t5 ON t0.manufacturerFK = t5.id LEFT OUTER JOIN
bidspec.categorytype t3 ON t2.categoryTypeFK = t3.id LEFT OUTER JOIN
bidspec.category t6 ON t5.typeFK = t6.id WHERE (UPPER(t1.name) = ? AND
UPPER(t0.loginName) = ?) ORDER BY t0.lastName ASC, t0.firstName ASC
[params=(String) BIDSPEC, (String) PMORAN]
33360  TRACE  [main] openjpa.jdbc.SQL - t 19399109, conn 28442012 [0 ms] spent
0|false|0.9.6-incubating org.apache.openjpa.persistence.PersistenceException:
null
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:851)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:748)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:773)
at
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:254)
at
org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2115)
at
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:248)
at
org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObject(Inst
anceResultObjectProvider.java:56)
at
org.apache.openjpa.lib.rop.EagerResultList.init(EagerResultList.java:33)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1203)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:979)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:832)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:763)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:520)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:212)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:251)
at
ca.BidSpec.emall.user.PersonFactoryImpl.getLoginPersonValueObject(PersonFactoryI
mpl.java:98)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils
.java:304)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(Ref
lectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveM
ethodInvocation.java:139)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(Transa
ctionInterceptor.java:107)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveM
ethodInvocation.java:161)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.j
ava:203)
at $Proxy34.getLoginPersonValueObject(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils
.java:304)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(Ref
lectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveM
ethodInvocation.java:139)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(Transa
ctionInterceptor.java:107)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveM
ethodInvocation.java:161)
at

RE: [jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.

 Does that mean you store Strings as arrays of integers by 
 default for the same reason?

No.

 Why is this different?

Because we've regularly run into problems with chars, and have found
that mapping them as ints by default gets around the problems.

 There aren't any non-incubator openjpa releases yet, so I 
 don't see the problem. 

Any other opinions?

 I'd also expect that for preexisting 
 tables either an INTEGER or CHAR column would work.

They do, as long as you configure things correctly.

  openjpa.Log: SQL=TRACE
 
 Where would I put this so I could see what the unit tests were doing?

What are the unit tests? Your tests, or the tests in the OpenJPA
project?

For your tests, add a property name=openjpa.Log value=SQL=TRACE/
to your persistence unit. See
http://incubator.apache.org/openjpa/docs/latest/manual/manual.html#ref_g
uide_logging.

 (1) is a lot more important, but changing the answer to (2) 
 is easier and solves my immediate problem.

I don't think that 1 is important, since you can trivially set
storeCharsAsNumbers to true. Ditto for 2.

-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: David Jencks [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 18, 2007 3:20 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [jira] Commented: (OPENJPA-221) DerbyDictionary 
 doesn't describe a working mapping for char fields.
 
 
 On Apr 18, 2007, at 11:12 AM, Patrick Linskey wrote:
 
  Hi,
 
 
  IIUC derby is a pure java db optimized for use with java 
 and storing 
  java primitive types basically using java serialization.  
 Why would 
  openjpa want to store a char in derby as an integer?
 
  Because we've always done it that way. Is there a reason why we 
  should not be storing chars as numbers? Historically, we've seen 
  problems with comparisons and localization issues when 
 storing chars 
  as chars, which is why we store them as ints by default.
 
 Does that mean you store Strings as arrays of integers by 
 default for the same reason?  Why is this different?
 
  Based on the fact that you said
  that the unit tests fail with Derby with that configuration 
 change, it 
  sounds like there are some sorts of issues with char mappings in 
  Derby.
 
 The unit tests fail with only the storeCharsAsIntegers=false 
 because the sql for creating the table is invalid.  They 
 succeed with the additional patch to create a CHAR(1) column 
 instead of CHAR(255) for a char field.  I'm happy to discuss 
 if creating a  CHAR(255) column to store a char field is 
 reasonable :-)
 
  Additionally, since we've always done it that way, changing 
 would mean 
  backwards-compatibility problems.
 
 There aren't any non-incubator openjpa releases yet, so I 
 don't see the problem.  I'd also expect that for preexisting 
 tables either an INTEGER or CHAR column would work.
 
 
  Why are the current settings correct, despite not working with the 
  obvious char  CHAR mapping?
 
  How do you define not working? It's my expectation that if the 
  application behaves as expected, then things are working. It sounds 
  like what you're saying is the default is not what was 
 expected, not 
  that things don't work.
 
 I expect that if I have a char field in an object and a 
 preexisting table with a CHAR column openjpa will figure out 
 some way to get a char from the field to the column and back 
 again without any additional configuration, for all 
 databases.  Admittedly my proposed fix only does this for 
 derby, and by changing the default mapping for chars for derby.
 
 I additionally expect that if openjpa creates a schema for me 
 for a database with default utf support it will map a char 
 field to a CHAR column.  I wouldn't necessarily expect this 
 for a database that by default doesn't have utf columns.
 
 
  I haven't found the magic setting so I can see what table is being 
  created for the unit tests
 
  openjpa.Log: SQL=TRACE
 
 Where would I put this so I could see what the unit tests were doing?
 
 I think there are 2 issues here:
 
 1. should openjpa be able to use a preexisting CHAR column 
 for storing a char, no matter what the storeCharsAsInteger setting is?
 2. should the settings for derby be storeCharsAsInteger = 
 false or true?
 
 (1) is a lot more important, but changing the answer to (2) 
 is easier and solves my immediate problem.
 
 thanks
 david jencks
 
 
  -Patrick
 
  --
  Patrick Linskey
  BEA Systems, Inc.

Re: [VOTE] publish openjpa 0.9.7-incubating release


I probably should have worded that differently since I haven't run the tests
against DB2. I believe Dave's team has.

Dave, can you comment on how big the impact of OpenJPA-222 is?

On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote:


 I'm a little nervous about OpenJPA-222. From talking with
 Dave it sounds like it has a large effect on DB2. I'd like to
 get that issue resolved if possible.

I'm a little nervous about scope creep. Is there some good reason why
OPENJPA-222 needs to be resolved now vs. later?

-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: Michael Dick [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 18, 2007 2:24 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release

 On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
 
  Michael-
 
  On Apr 18, 2007, at 12:27 PM, Michael Dick wrote:
 
   I'd rather not cut another release, but I think we do need to
   resolve the issue with the docbook jar. If we can live with the
   extra jar then the vote can proceed.
 
  Personally, I think it is sufficiently ugly to release with the
  docbook jar to justify starting another release.

 However, if others disagree, I'll happily accede to the majority. For
  now, my vote changes to +0.
 
 
  I agree but like you I can be talked out of it. I'll take
 another look
 over everything and start another release tonight / tomorrow.

 I'm a little nervous about OpenJPA-222. From talking with
 Dave it sounds like it has a large effect on DB2. I'd like to
 get that issue resolved if possible.


 --
 -Michael Dick


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.





--
-Michael Dick

Re: [VOTE] publish openjpa 0.9.7-incubating release