Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java

2007-04-03 Thread Craig L Russell 

Hi David,

The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.  
Can you please fix this?


Craig

public String getForUpdateClause(JDBCFetchConfiguration fetch,  
boolean forUpdate) {

String isolationLevel = null;
Boolean updateClause = null;
DatabaseMetaData metaData = null;
StringBuffer forUpdateString = new StringBuffer();
try {
// Determine the update clause/isolationLevel the hint
// overrides the persistence.xml value
if (fetch != null  fetch.getHint 
(openjpa.hint.updateClause)

!=null )
updateClause = (Boolean)fetch.
getHint(openjpa.hint.updateClause);
else
updateClause = forUpdate;  
=== here
if (fetch != null fetch.getHint 
(openjpa.hint.isolationLevel)

!=null )
isolationLevel = (String)fetch.
getHint(openjpa.hint.isolationLevel);
else
isolationLevel = conf.getTransactionIsolation();
if (updateClause == false)  
=== here
//This sql is not for update so add FOR Read Only  
clause

forUpdateString.append( ).append(forReadOnlyClause)
.append( );
else if (updateClause == true) 
{ === here



On Apr 3, 2007, at 12:35 PM, [EMAIL PROTECTED] wrote:


Author: wisneskid
Date: Tue Apr  3 12:34:59 2007
New Revision: 525252

URL: http://svn.apache.org/viewvc?view=revrev=525252
Log:
changes for JIRA OPENJPA-182

Modified:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ 
openjpa/jdbc/sql/AbstractDB2Dictionary.java
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ 
openjpa/jdbc/sql/DB2Dictionary.java


Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/ 
apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa- 
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/ 
AbstractDB2Dictionary.java?view=diffrev=525252r1=525251r2=525252
== 

--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ 
openjpa/jdbc/sql/AbstractDB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ 
openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr  3 12:34:59 2007

@@ -52,7 +52,7 @@
 supportsLockingWithOrderClause = false;
 supportsLockingWithOuterJoin = false;
 supportsLockingWithInnerJoin = false;
-supportsLockingWithSelectRange = false;
+supportsLockingWithSelectRange = true;

 requiresAutoCommitForMetaData = true;
 requiresAliasForSubselect = true;

Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/ 
apache/openjpa/jdbc/sql/DB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa- 
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java? 
view=diffrev=525252r1=525251r2=525252
== 

--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ 
openjpa/jdbc/sql/DB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ 
openjpa/jdbc/sql/DB2Dictionary.java Tue Apr  3 12:34:59 2007

@@ -15,13 +15,15 @@
  */
 package org.apache.openjpa.jdbc.sql;

+import java.lang.reflect.Method;
 import java.sql.Connection;
 import java.sql.DatabaseMetaData;
 import java.sql.SQLException;
 import java.util.Arrays;
-
+import java.util.StringTokenizer;
 import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
 import org.apache.openjpa.jdbc.schema.Sequence;
+import org.apache.openjpa.lib.log.Log;

 /**
  * Dictionary for IBM DB2 database.
@@ -31,7 +33,18 @@

 public String optimizeClause = optimize for;
 public String rowClause = row;
-
+private int db2ServerType = 0;
+private static final int  db2ISeriesV5R3AndEarlier = 1;
+private static final int db2UDBV81OrEarlier = 2;
+private static final int db2ZOSV8x = 3;
+private static final int db2UDBV82AndLater = 4;
+private static final int  db2ISeriesV5R4AndLater = 5;
+   private static final String  forUpdateOfClause=FOR UPDATE OF;
+private static final String  withRSClause=WITH RS;
+private static final String  withRRClause=WITH RR;
+private static final String  useKeepUpdateLockClause= USE AND  
KEEP UPDATE LOCKS;
+private static final String  useKeepExclusiveLockClause=USE  
AND KEEP EXCLUSIVE LOCKS;

+private static final String  forReadOnlyClause = FOR READ ONLY;
 public DB2Dictionary() {
 platform = DB2;
 validationSQL = SELECT DISTINCT(CURRENT TIMESTAMP) FROM 
@@ -170,6 +183,18 @@
if (isJDBC3(metaData)) {

RE: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java

2007-04-03 Thread Patrick Linskey 
I'm a little nervous about this change still. I don't like it that we're
adding yet another way to configure locking, especially since it seems
like the lock level settings should be sufficient (or nearly so) to
handle per-transaction / per-query lock levels.

I also still do not believe that isolationLevel should be a hint; it
seems more rule-like than hint-like.

To date, the OpenJPA model has not been to piggyback on the
Query.setHint() facilities for vendor-specific metadata, but rather to
use our OpenJPA extension classes (FetchPlan, etc.) to allow us to
convey more structured data to the kernel. I think that the isolation
level should probably be part of FetchPlan (or possibly JDBCFetchPlan),
and the update information should be obtainable from the FetchPlan's
read- and write-lock levels.

I don't think that we should rush this change in just so it's in 0.9.7;
we can always delay 0.9.7 if it's a must-have, or have a 0.9.8 that
follows soon thereafter. Generally-speaking, my experience is that once
code gets committed, it tends to not get cleaned up, so the argument
let's get it in for the release and then fix it later usually ends up
turning into let's get it in for the release. This seems especially
true for a change like this, that is exposing new APIs (the hints).

Thoughts?

-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: Tuesday, April 03, 2007 12:35 PM
 To: open-jpa-commits@incubator.apache.org
 Subject: svn commit: r525252 - in 
 /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache
 /openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
 
 Author: wisneskid
 Date: Tue Apr  3 12:34:59 2007
 New Revision: 525252
 
 URL: http://svn.apache.org/viewvc?view=revrev=525252
 Log:
 changes for JIRA OPENJPA-182
 
 Modified:
 
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java
 
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java
 
 Modified: 
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java
 URL: 
 http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-j
dbc/src/main/java/org/apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java
?view=diffrev= 525252r1=525251r2=525252
 ==
 
 --- 
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java (original)
 +++ 
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr  3 12:34:59 2007
 @@ -52,7 +52,7 @@
  supportsLockingWithOrderClause = false;
  supportsLockingWithOuterJoin = false;
  supportsLockingWithInnerJoin = false;
 -supportsLockingWithSelectRange = false;
 +supportsLockingWithSelectRange = true;
  
  requiresAutoCommitForMetaData = true;
  requiresAliasForSubselect = true;
 
 Modified: 
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java
 URL: 
 http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-j
dbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java?view=di
ffrev=525252r1= 525251r2=525252
 ==
 
 --- 
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java (original)
 +++ 
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java Tue Apr  3 12:34:59 2007
 @@ -15,13 +15,15 @@
   */
  package org.apache.openjpa.jdbc.sql;
  
 +import java.lang.reflect.Method;
  import java.sql.Connection;
  import java.sql.DatabaseMetaData;
  import java.sql.SQLException;
  import java.util.Arrays;
 -
 +import java.util.StringTokenizer;
  import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
  import org.apache.openjpa.jdbc.schema.Sequence;
 +import org.apache.openjpa.lib.log.Log;
  
  /**
   * Dictionary for IBM DB2 database.
 @@ -31,7 +33,18 @@
  
  public String optimizeClause = optimize for;
  public String rowClause = row;
 -
 +private int db2ServerType = 0; 
 +private static final int  db2ISeriesV5R3AndEarlier = 1;
 +private static final int db2UDBV81OrEarlier = 2;
 +

Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java

2007-04-03 Thread Abe White 
 The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.  
 Can you please fix this?

And I'd like to see all those hints defined as static constants on  
the dictionary class and named for DB2 (if they're that specific) and  
capitalized while you're at it -- see OracleDictionary.SELECT_HINT  
for a template.

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: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java

2007-04-03 Thread Ritika Maheshwari 

yes will do that

ritika


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


Hi David,

The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.
Can you please fix this?

Craig

public String getForUpdateClause(JDBCFetchConfiguration fetch,
boolean forUpdate) {
String isolationLevel = null;
Boolean updateClause = null;
DatabaseMetaData metaData = null;
StringBuffer forUpdateString = new StringBuffer();
try {
// Determine the update clause/isolationLevel the hint
// overrides the persistence.xml value
if (fetch != null  fetch.getHint
(openjpa.hint.updateClause)
!=null )
updateClause = (Boolean)fetch.
getHint(openjpa.hint.updateClause);
else
updateClause = forUpdate;
=== here
if (fetch != null fetch.getHint
(openjpa.hint.isolationLevel)
!=null )
isolationLevel = (String)fetch.
getHint(openjpa.hint.isolationLevel);
else
isolationLevel = conf.getTransactionIsolation();
if (updateClause == false)
=== here
//This sql is not for update so add FOR Read Only
clause
forUpdateString.append( ).append(forReadOnlyClause)
.append( );
else if (updateClause == true)
{ === here


On Apr 3, 2007, at 12:35 PM, [EMAIL PROTECTED] wrote:

 Author: wisneskid
 Date: Tue Apr  3 12:34:59 2007
 New Revision: 525252

 URL: http://svn.apache.org/viewvc?view=revrev=525252
 Log:
 changes for JIRA OPENJPA-182

 Modified:
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/AbstractDB2Dictionary.java
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/DB2Dictionary.java

 Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
 apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java
 URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
 jdbc/src/main/java/org/apache/openjpa/jdbc/sql/
 AbstractDB2Dictionary.java?view=diffrev=525252r1=525251r2=525252
 ==
 
 --- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/AbstractDB2Dictionary.java (original)
 +++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr  3 12:34:59 2007
 @@ -52,7 +52,7 @@
  supportsLockingWithOrderClause = false;
  supportsLockingWithOuterJoin = false;
  supportsLockingWithInnerJoin = false;
 -supportsLockingWithSelectRange = false;
 +supportsLockingWithSelectRange = true;

  requiresAutoCommitForMetaData = true;
  requiresAliasForSubselect = true;

 Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
 apache/openjpa/jdbc/sql/DB2Dictionary.java
 URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
 jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java?
 view=diffrev=525252r1=525251r2=525252
 ==
 
 --- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/DB2Dictionary.java (original)
 +++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/DB2Dictionary.java Tue Apr  3 12:34:59 2007
 @@ -15,13 +15,15 @@
   */
  package org.apache.openjpa.jdbc.sql;

 +import java.lang.reflect.Method;
  import java.sql.Connection;
  import java.sql.DatabaseMetaData;
  import java.sql.SQLException;
  import java.util.Arrays;
 -
 +import java.util.StringTokenizer;
  import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
  import org.apache.openjpa.jdbc.schema.Sequence;
 +import org.apache.openjpa.lib.log.Log;

  /**
   * Dictionary for IBM DB2 database.
 @@ -31,7 +33,18 @@

  public String optimizeClause = optimize for;
  public String rowClause = row;
 -
 +private int db2ServerType = 0;
 +private static final int  db2ISeriesV5R3AndEarlier = 1;
 +private static final int db2UDBV81OrEarlier = 2;
 +private static final int db2ZOSV8x = 3;
 +private static final int db2UDBV82AndLater = 4;
 +private static final int  db2ISeriesV5R4AndLater = 5;
 + private static final String  forUpdateOfClause=FOR UPDATE OF;
 +private static final String  withRSClause=WITH RS;
 +private static final String  withRRClause=WITH RR;
 +private static final String  useKeepUpdateLockClause= USE AND
 KEEP UPDATE LOCKS;
 +private static final String  useKeepExclusiveLockClause=USE
 AND KEEP EXCLUSIVE LOCKS;
 +private static final String  forReadOnlyClause = FOR READ ONLY;
  public DB2Dictionary() {
  platform = DB2;

Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java

2007-04-03 Thread Craig L Russell 
Never mind. I fixed it. I guess we still need to decide whether the  
change goes in, but meantime it should compile...


Craig

On Apr 3, 2007, at 12:58 PM, Ritika Maheshwari wrote:


yes will do that

ritika


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


Hi David,

The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.
Can you please fix this?

Craig

public String getForUpdateClause(JDBCFetchConfiguration fetch,
boolean forUpdate) {
String isolationLevel = null;
Boolean updateClause = null;
DatabaseMetaData metaData = null;
StringBuffer forUpdateString = new StringBuffer();
try {
// Determine the update clause/isolationLevel the hint
// overrides the persistence.xml value
if (fetch != null  fetch.getHint
(openjpa.hint.updateClause)
!=null )
updateClause = (Boolean)fetch.
getHint(openjpa.hint.updateClause);
else
updateClause = forUpdate;
=== here
if (fetch != null fetch.getHint
(openjpa.hint.isolationLevel)
!=null )
isolationLevel = (String)fetch.
getHint(openjpa.hint.isolationLevel);
else
isolationLevel = conf.getTransactionIsolation();
if (updateClause == false)
=== here
//This sql is not for update so add FOR Read Only
clause
forUpdateString.append( ).append(forReadOnlyClause)
.append( );
else if (updateClause == true)
{ === here


On Apr 3, 2007, at 12:35 PM, [EMAIL PROTECTED] wrote:

 Author: wisneskid
 Date: Tue Apr  3 12:34:59 2007
 New Revision: 525252

 URL: http://svn.apache.org/viewvc?view=revrev=525252
 Log:
 changes for JIRA OPENJPA-182

 Modified:
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/AbstractDB2Dictionary.java
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/DB2Dictionary.java

 Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
 apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java
 URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
 jdbc/src/main/java/org/apache/openjpa/jdbc/sql/
 AbstractDB2Dictionary.java?view=diffrev=525252r1=525251r2=525252
  
= 
=

 
 --- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/AbstractDB2Dictionary.java (original)
 +++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr  3 12:34:59  
2007

 @@ -52,7 +52,7 @@
  supportsLockingWithOrderClause = false;
  supportsLockingWithOuterJoin = false;
  supportsLockingWithInnerJoin = false;
 -supportsLockingWithSelectRange = false;
 +supportsLockingWithSelectRange = true;

  requiresAutoCommitForMetaData = true;
  requiresAliasForSubselect = true;

 Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
 apache/openjpa/jdbc/sql/DB2Dictionary.java
 URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
 jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java?
 view=diffrev=525252r1=525251r2=525252
  
= 
=

 
 --- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/DB2Dictionary.java (original)
 +++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
 openjpa/jdbc/sql/DB2Dictionary.java Tue Apr  3 12:34:59 2007
 @@ -15,13 +15,15 @@
   */
  package org.apache.openjpa.jdbc.sql;

 +import java.lang.reflect.Method;
  import java.sql.Connection;
  import java.sql.DatabaseMetaData;
  import java.sql.SQLException;
  import java.util.Arrays;
 -
 +import java.util.StringTokenizer;
  import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
  import org.apache.openjpa.jdbc.schema.Sequence;
 +import org.apache.openjpa.lib.log.Log;

  /**
   * Dictionary for IBM DB2 database.
 @@ -31,7 +33,18 @@

  public String optimizeClause = optimize for;
  public String rowClause = row;
 -
 +private int db2ServerType = 0;
 +private static final int  db2ISeriesV5R3AndEarlier = 1;
 +private static final int db2UDBV81OrEarlier = 2;
 +private static final int db2ZOSV8x = 3;
 +private static final int db2UDBV82AndLater = 4;
 +private static final int  db2ISeriesV5R4AndLater = 5;
 + private static final String  forUpdateOfClause=FOR UPDATE  
OF;

 +private static final String  withRSClause=WITH RS;
 +private static final String  withRRClause=WITH RR;
 +private static final String  useKeepUpdateLockClause= USE AND
 KEEP UPDATE LOCKS;
 +private static final String

Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java

2007-04-03 Thread David Wisneski 

SQL provides capabilities for tuning of locking.  In the case of DB2
this involves setting the isolation level, update lock, result set
optimize set, etc.
JPA spec does not provide support for these concepts but does provide a rather
open ended setHint api.  It is our intent to make use this api so that
users can
sets these values without having to make use of OpenJPA specific apis
-- granted the hint name and value would be OpenJPA specific.
Furthermore, we are intending to support static SQL.  Static SQL is
extremely important in the enterprise environment for our larger
customers because (1) it provides better optimization of SQL and (2)
auditability and security over who access the data and how it is
accessed.In the case of static SQL,  these hints would be defined
on a NamedQuery definition and not through runtime api.

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

I'm a little nervous about this change still. I don't like it that we're
adding yet another way to configure locking, especially since it seems
like the lock level settings should be sufficient (or nearly so) to
handle per-transaction / per-query lock levels.

I also still do not believe that isolationLevel should be a hint; it
seems more rule-like than hint-like.

To date, the OpenJPA model has not been to piggyback on the
Query.setHint() facilities for vendor-specific metadata, but rather to
use our OpenJPA extension classes (FetchPlan, etc.) to allow us to
convey more structured data to the kernel. I think that the isolation
level should probably be part of FetchPlan (or possibly JDBCFetchPlan),
and the update information should be obtainable from the FetchPlan's
read- and write-lock levels.

I don't think that we should rush this change in just so it's in 0.9.7;
we can always delay 0.9.7 if it's a must-have, or have a 0.9.8 that
follows soon thereafter. Generally-speaking, my experience is that once
code gets committed, it tends to not get cleaned up, so the argument
let's get it in for the release and then fix it later usually ends up
turning into let's get it in for the release. This seems especially
true for a change like this, that is exposing new APIs (the hints).

Thoughts?

-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: Tuesday, April 03, 2007 12:35 PM
 To: open-jpa-commits@incubator.apache.org
 Subject: svn commit: r525252 - in
 /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache
 /openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java

 Author: wisneskid
 Date: Tue Apr  3 12:34:59 2007
 New Revision: 525252

 URL: http://svn.apache.org/viewvc?view=revrev=525252
 Log:
 changes for JIRA OPENJPA-182

 Modified:

 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java

 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java

 Modified:
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java
 URL:
 http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-j
dbc/src/main/java/org/apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java
?view=diffrev= 525252r1=525251r2=525252
 ==
 
 ---
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java (original)
 +++
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr  3 12:34:59 2007
 @@ -52,7 +52,7 @@
  supportsLockingWithOrderClause = false;
  supportsLockingWithOuterJoin = false;
  supportsLockingWithInnerJoin = false;
 -supportsLockingWithSelectRange = false;
 +supportsLockingWithSelectRange = true;

  requiresAutoCommitForMetaData = true;
  requiresAliasForSubselect = true;

 Modified:
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java
 URL:
 http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-j
dbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java?view=di
ffrev=525252r1= 525251r2=525252
 ==
 
 ---
 incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java (original)
 +++

RE: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java

2007-04-03 Thread Patrick Linskey 
 open ended setHint api.  It is our intent to make use this api so that
 users can
 sets these values without having to make use of OpenJPA specific apis
 -- granted the hint name and value would be OpenJPA specific.

... for certain values of our. I think that it's important that we
discuss API decisions as a group, as they have significant impacts on
the OpenJPA product moving forward. This is especially important when
there are dissenting views on a particular API decision, as is the case
here.

Currently, most of the precedent in OpenJPA is to use OpenJPA-specific
APIs, rather than untyped strings, whenever possible for fetch
configuration and behavior. See the APIs for controlling the fetch batch
size, or the lock level, or the maximum fetch depth. Personally, I much
prefer that model of operation, since it provides strong typing where
vendor-specific extensions are used, and thus raises the awareness of
developers that they are using a proprietary feature. Using string
key-value pairs is notoriously error-prone and difficult to refactor,
and in my opinion detracts from the usability of the API.

 accessed.In the case of static SQL,  these hints would be defined
 on a NamedQuery definition and not through runtime api.

Again, I don't think that 'hint' is really the right word for describing
lock and isolation levels.

We could also create new annotations to describe the lock levels and
isolation settings needed for the named queries; we do not need to
constrain ourselves to what is available in the JPA annotations / XML.
This will mean a bit more work on our part, but I think that we should
figure out what the right decision is for our users, and work from
there, rather than just doing whatever fits into what the JPA spec
provides API-wise.

Similarly, these facilities seem useful for regular EM.find() calls; one
of the nice things about the FetchPlan is that an EM has a FetchPlan and
a Query has one, so similar fetching configurations can be implemented
in a common manner.

Thoughts?

-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 Wisneski [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, April 03, 2007 1:24 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: svn commit: r525252 - in 
 /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache
 /openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
 
 SQL provides capabilities for tuning of locking.  In the case of DB2
 this involves setting the isolation level, update lock, result set
 optimize set, etc.
 JPA spec does not provide support for these concepts but does 
 provide a rather
 open ended setHint api.  It is our intent to make use this api so that
 users can
 sets these values without having to make use of OpenJPA specific apis
 -- granted the hint name and value would be OpenJPA specific.
 Furthermore, we are intending to support static SQL.  Static SQL is
 extremely important in the enterprise environment for our larger
 customers because (1) it provides better optimization of SQL and (2)
 auditability and security over who access the data and how it is
 accessed.In the case of static SQL,  these hints would be defined
 on a NamedQuery definition and not through runtime api.
 
 On 4/3/07, Patrick Linskey [EMAIL PROTECTED] wrote:
  I'm a little nervous about this change still. I don't like 
 it that we're
  adding yet another way to configure locking, especially 
 since it seems
  like the lock level settings should be sufficient (or nearly so) to
  handle per-transaction / per-query lock levels.
 
  I also still do not believe that isolationLevel should be a hint; it
  seems more rule-like than hint-like.
 
  To date, the OpenJPA model has not been to piggyback on the
  Query.setHint() facilities for vendor-specific metadata, 
 but rather to
  use our OpenJPA extension classes (FetchPlan, etc.) to allow us to
  convey more structured data to the kernel. I think that the 
 isolation
  level should probably be part of FetchPlan (or possibly 
 JDBCFetchPlan),
  and the update information should be obtainable from the FetchPlan's
  read- and write-lock levels.
 
  I don't think that we should rush this change in just so 
 it's in 0.9.7;
  we can always delay 0.9.7 if it's a must-have, or have a 0.9.8 that
  follows soon thereafter. Generally-speaking, my experience 
 is that once
  code gets committed, it tends to not get cleaned up, so the argument

Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java

2007-04-03 Thread David Wisneski 

My experience is that customers don't like and tend not to use
proprietary apis.  They tend to understand and use the standard apis.
If we can make a standard api do what we need that should be the
preferrred approach over creating proprietary apis and annotations and
then having to educate folks on how to use them.  The JPA Hint was
supposed to be a way to specify properties on a per query basis and
that is exactly what we are trying to do in this case.

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

 open ended setHint api.  It is our intent to make use this api so that
 users can
 sets these values without having to make use of OpenJPA specific apis
 -- granted the hint name and value would be OpenJPA specific.

... for certain values of our. I think that it's important that we
discuss API decisions as a group, as they have significant impacts on
the OpenJPA product moving forward. This is especially important when
there are dissenting views on a particular API decision, as is the case
here.

Currently, most of the precedent in OpenJPA is to use OpenJPA-specific
APIs, rather than untyped strings, whenever possible for fetch
configuration and behavior. See the APIs for controlling the fetch batch
size, or the lock level, or the maximum fetch depth. Personally, I much
prefer that model of operation, since it provides strong typing where
vendor-specific extensions are used, and thus raises the awareness of
developers that they are using a proprietary feature. Using string
key-value pairs is notoriously error-prone and difficult to refactor,
and in my opinion detracts from the usability of the API.

 accessed.In the case of static SQL,  these hints would be defined
 on a NamedQuery definition and not through runtime api.

Again, I don't think that 'hint' is really the right word for describing
lock and isolation levels.

We could also create new annotations to describe the lock levels and
isolation settings needed for the named queries; we do not need to
constrain ourselves to what is available in the JPA annotations / XML.
This will mean a bit more work on our part, but I think that we should
figure out what the right decision is for our users, and work from
there, rather than just doing whatever fits into what the JPA spec
provides API-wise.

Similarly, these facilities seem useful for regular EM.find() calls; one
of the nice things about the FetchPlan is that an EM has a FetchPlan and
a Query has one, so similar fetching configurations can be implemented
in a common manner.

Thoughts?

-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 Wisneski [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, April 03, 2007 1:24 PM
 To: open-jpa-dev@incubator.apache.org
 Subject: Re: svn commit: r525252 - in
 /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache
 /openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java

 SQL provides capabilities for tuning of locking.  In the case of DB2
 this involves setting the isolation level, update lock, result set
 optimize set, etc.
 JPA spec does not provide support for these concepts but does
 provide a rather
 open ended setHint api.  It is our intent to make use this api so that
 users can
 sets these values without having to make use of OpenJPA specific apis
 -- granted the hint name and value would be OpenJPA specific.
 Furthermore, we are intending to support static SQL.  Static SQL is
 extremely important in the enterprise environment for our larger
 customers because (1) it provides better optimization of SQL and (2)
 auditability and security over who access the data and how it is
 accessed.In the case of static SQL,  these hints would be defined
 on a NamedQuery definition and not through runtime api.

 On 4/3/07, Patrick Linskey [EMAIL PROTECTED] wrote:
  I'm a little nervous about this change still. I don't like
 it that we're
  adding yet another way to configure locking, especially
 since it seems
  like the lock level settings should be sufficient (or nearly so) to
  handle per-transaction / per-query lock levels.
 
  I also still do not believe that isolationLevel should be a hint; it
  seems more rule-like than hint-like.
 
  To date, the OpenJPA model has not been to piggyback on the
  Query.setHint() facilities for vendor-specific metadata,
 but rather to
  use our OpenJPA extension classes (FetchPlan, etc.) to allow us to
  convey more structured data to the kernel. I