[jira] Created: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.
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 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.
[jira] Updated: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.
[ https://issues.apache.org/jira/browse/OPENJPA-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated OPENJPA-221: - Attachment: OPENJPA-221.patch This patch results in a working mapping from a char field to a CHAR column. I also added some comments to the defaults in DBDictionary that I hope are correct and helpful. > 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.
[jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.
[ https://issues.apache.org/jira/browse/OPENJPA-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489761 ] Patrick Linskey commented on OPENJPA-221: - What happens if, without your patch, you set the DBDictionary 'StoreCharsAsNumbers' property to false? ... > 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.
[jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.
[ https://issues.apache.org/jira/browse/OPENJPA-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489791 ] David Jencks commented on OPENJPA-221: -- I'm not in a position to easily modify the applications in question (they are in the tck) but if I only set storeCharsAsNumbers=false in code then I got a lot of openjpa unit test errors complaining that it couldn't create the table for AllFieldTypes, something about CHAR(255). changing the other property fixed that. If I turned off the unit tests then openjpa worked fine with preexisting derby tables with a CHAR column for the char field. Is this enough info? > 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
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: /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: /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 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/ > > resources/org/apache/openjpa/persistence/persistence-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-jdbc/ > > derby.log > > ok: This should be cleaned up for future releases but has no IP > > > > openjpa-project-0.9.7-incubating-source/openjpa-persistence-jdbc/src/ > > test/resources/org/apache/openjpa/persistence/xml/orm.xml > > ok: This is a test case
Re: [VOTE] publish openjpa 0.9.7-incubating release
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
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-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/ >> > > wind
Re: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH 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.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 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
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
RE: [VOTE] publish openjpa 0.9.7-incubating release
> - The binary distribution contains a new JAR file whose > license is unclear; this is: > /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: > /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: > /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-proj
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: > /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: > /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: > /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: > /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-pro
[jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.
[ 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
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: /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).
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: > > > /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: > > > /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: > > > /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: > > > /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.
RE: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH 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 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 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 m
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: > >> /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.
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: /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 > >> >
[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?
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: /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: /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
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: > /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: > /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: /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: > >> /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: > >> /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
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
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: /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: /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: /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: /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 in
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: > /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: > /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?
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,
--
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
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: >> > /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: >> > /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
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: >> > /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: >> > /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). >> > >> >> > >> >>
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: > >> >> > /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 att
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: /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 fi
RE: Named query created in error
These are all mainly many-to-one, but regardless are these not suppose to build persistent objects? How can they do this if they mix data from several tables (I am using table/class inheritance). The exception I get is null pointer from this line: List results = (List) q.getResultList(); The query has both params populated on the input side. I can change to lazy fetch but I would hope that his would not change the query and cause it to suddenly work. An interesting aside - I changed the named query to look like this @NamedQuery(name = "PersonFXStoreAndLogin", query = "SELECT p FROM Person p, IN(p.store) s WHERE UPPER(s.name) = :storeName and UPPER(p.loginName) = :loginName ORDER BY p.lastName, p.firstName") }) And got the duplicate query I have asked about in the past. Also this generates a similar SQL statement and resulted in a NPE -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: April 18, 2007 3:56 PM To: open-jpa-dev@incubator.apache.org Subject: 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
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.
[jira] Updated: (OPENJPA-222) FOR READ ONLY clause getting generated for subselects
[ https://issues.apache.org/jira/browse/OPENJPA-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick updated OPENJPA-222: - Attachment: JIRA182-subselect.patch Attaching Ritika's patch here. > 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 > 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.
[jira] Created: (OPENJPA-223) columnNames field of @Index annotation is ignored
columnNames field of @Index annotation is ignored
-
Key: OPENJPA-223
URL: https://issues.apache.org/jira/browse/OPENJPA-223
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Affects Versions: 0.9.6
Reporter: Marc Prud'hommeaux
It looks like we completely ignore the "columnNames" field of the
org.apache.openjpa.persistence.jdbc.Index annotation. From Jonathan Feinberg on
the mailing list:
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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
[ 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: [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
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
On 4/18/07, Phill Moran <[EMAIL PROTECTED]> wrote: The exception I get is null pointer from this line: List results = (List) q.getResultList(); Could you show the query creation and the stack trace you're getting? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Spurious warnings during runtime schema update
On 4/18/07, Jonathan Feinberg <[EMAIL PROTECTED]> wrote: 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 schemadefinition. 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 What database are you using? Have you tried to run it against another db? I suspect it might be related to the db. Could you try out the following setting in your persistence.xml: ? What's the result? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
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. __ _ 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 storeChar
RE: Named query created in error
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 - 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 - [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.(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 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.j ava:203)
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 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
RE: [VOTE] publish openjpa 0.9.7-incubating release
> 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.
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
This isn't the last release of openjpa. What is the urgency for fixing this before our major event (the last release before exiting the incubator)? Is this release planned to be bundled with some other significant release? Craig On Apr 18, 2007, at 4:40 PM, Michael Dick wrote: 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 Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.
First, let me observe that Java char is a single entity that represents one of 65535 or so different items, more if you are trying to represent characters in Chinese that require Unicode-4 byte representation. Most databases treat CHAR(1) as a single byte, which is great for ASCII 8 but woefully inadequate for representing Java char. 1. For the best accuracy in all databases, mapping char to String.valueOf((int)char) is bound to be correct. 2. But if the user wants to lose precision and save a few bytes in the database, mapping directly from char to CHAR(1) is ideal. It doesn't seem to me that there is a single "best" solution to this issue. Historically, Kodo mapped char to INTEGER or VARCHAR column types and there is nothing intrinsically wrong with this. On the other hand, if the column type is CHAR(1) there is no way to represent any of the ASCII characters 0-9;a-z;A-Z so there is something to be said for assuming a different mapping in this case. I don't know how feasible it is, but maybe if openjpa can detect that the column used to store a char is defined as SQL CHAR(1) then the mapping to the database character is used. And we can then depend on the database to signal that it's unhappy with storing a char that doesn't fit. Craig On Apr 18, 2007, at 3:37 PM, Patrick Linskey wrote: 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 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 expec
@ElementDependent and cascade-delete
Hi there, I have a list which is marked @ElementDependent and also CascadeType.ALL. Adding and removing items from the list works fine, and those elements are deleted from the database. When I try to delete the owning entity though, I get the exception below. I can delete the entity okay if I delete all the elements of the list first. Am I doing something wrong? I get the same behaviour on 0.9.6 and 0.9.7. Thanks, Roger <2|false|0.9.6-incubating> org.apache.openjpa.persistence.OptimisticLockException: An optimistic lock violation was detected when flushing object instance "figbird.users.entities.RoleMapping-figbird.users.entities.RoleMapping-5" to the data store. This indicates that the object was concurrently modified in another transaction. FailedObject: figbird.users.entities.RoleMapping-figbird.users.entities.RoleMapping-5 org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:96) org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:68) org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:159) org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:86) org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:86) org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:69) org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:511) org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:127) org.apache.openjpa.datacache.DataCacheStoreManager.flush(DataCacheStoreManager.java:506) org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:127) org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1927) org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1825) org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1756) org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:76) org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1313) org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:863) org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:377) seamless.application.EntityDAO.deleteEntity(EntityDAO.java:66) -- View this message in context: http://www.nabble.com/%40ElementDependent-and-cascade-delete-tf3604490.html#a10070525 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: Named query created in error
On 4/19/07, Phill Moran <[EMAIL PROTECTED]> wrote: 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 - 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 - [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) What database do you use? Show the line where the query is created and the parameters are passed. How do the persistence.xml look like? Do you happen to use orm.xml-like files? What Spring version is used? Show the Person entity (ca.BidSpec.emall.user.Person). I wonder why you only get the following warning message 25547 WARN [main] openjpa.MetaData - Found duplicate query "PersonFXLastFirst" in "class ca.BidSpec.emall.user.Person". Ignoring. , but there's no corresponding warning message for the entity behind p.store (possibly .Store). Do you happen to *not* annotate the Store class with @Entity? Could you attach the whole TRACE output of OpenJPA execution? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
