Re: svn commit: r510336 - /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java
Patrick,
This is really strange. At first, I thought this was just another case of
the line ending character problem. But, when I look at the svn history of
the DB2Dictionary.java file, it's as if this latest commit is the only
record of the file. But, when I look at previous revisions, the file does
exist. It's as if, the commit operation did a replace instead of an update
commit. I wasn't aware that this operation was even possible. I guess we
need to hear from Dave as to what operation he did to accidentally cause
this to happen.
Kevin
On 2/21/07, Patrick Linskey [EMAIL PROTECTED] wrote:
I don't get it. wasn't there already an
openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.jav
a?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 5:03 PM
To: open-jpa-commits@incubator.apache.org
Subject: svn commit: r510336 -
/incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache
/openjpa/jdbc/sql/DB2Dictionary.java
Author: wisneskid
Date: Wed Feb 21 17:03:06 2007
New Revision: 510336
URL: http://svn.apache.org/viewvc?view=revrev=510336
Log:
DB2 Optimize for clause enhancement
Added:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java
Added:
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=autorev=510336
==
---
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java (added)
+++
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java Wed Feb 21 17:03:06 2007
@@ -0,0 +1,210 @@
+/*
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in
writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
express or implied.
+ * See the License for the specific language governing
permissions and
+ * limitations under the License.
+ */
+package org.apache.openjpa.jdbc.sql;
+
+import java.sql.Connection;
+import java.sql.DatabaseMetaData;
+import java.sql.SQLException;
+import java.util.Arrays ;
+
+import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
+import org.apache.openjpa.jdbc.schema.Sequence;
+
+/**
+ * Dictionary for IBM DB2 database.
+ */
+public class DB2Dictionary
+extends AbstractDB2Dictionary {
+
+public DB2Dictionary() {
+platform = DB2;
+validationSQL = SELECT DISTINCT(CURRENT TIMESTAMP) FROM
++ SYSIBM.SYSTABLES;
+supportsSelectEndIndex = true;
+optimizeClause =optimize for;
+nextSequenceQuery = VALUES NEXTVAL FOR {0};
+
+sequenceSQL = SELECT SEQSCHEMA AS SEQUENCE_SCHEMA,
++ SEQNAME AS SEQUENCE_NAME FROM SYSCAT.SEQUENCES;
+sequenceSchemaSQL = SEQSCHEMA = ?;
+sequenceNameSQL = SEQNAME = ?;
+characterColumnSize = 254;
+
+binaryTypeName = BLOB(1M);
+longVarbinaryTypeName = BLOB(1M);
+varbinaryTypeName = BLOB(1M);
+clobTypeName = CLOB(1M);
+longVarcharTypeName = LONG VARCHAR;
+
+fixedSizeTypeNameSet.addAll (Arrays.asList(new String[]{
+LONG VARCHAR FOR BIT DATA, LONG VARCHAR,
LONG VARGRAPHIC,
+}));
+
+maxConstraintNameLength = 18;
+maxIndexNameLength = 18;
+maxColumnNameLength = 30;
+supportsDeferredConstraints = false;
+supportsDefaultDeleteAction = false;
+supportsAlterTableWithDropColumn = false;
+
+supportsNullTableForGetColumns = false;
+
+reservedWordSet.addAll(Arrays.asList(new String[]{
+AFTER, ALIAS, ALLOW, APPLICATION,
ASSOCIATE, ASUTIME,
+AUDIT, AUX, AUXILIARY, BEFORE, BINARY,
BUFFERPOOL,
+CACHE, CALL,
Re: svn commit: r510336 - /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java
Okay, I think we need to back out these last two changes and revert back to
revision 509885. Dave needs to go back to the drawing board for this db2
optimization change, probably create a JIRA report for this proposed
change, and use the design discussion associated with the JIRA process to
get the proper fix in place.
Something very strange happened with this latest commit and we lost the svn
history for the DB2Dictionary.java file. We should still try to figure out
what happened with svn to allow this. But, in the mean time, I think we
need to revert back to a known state.
I'll wait for some agreement (or disagreement) before doing any of the
cleanup.
Kevin
On 2/22/07, Kevin Sutter [EMAIL PROTECTED] wrote:
Patrick,
This is really strange. At first, I thought this was just another case of
the line ending character problem. But, when I look at the svn history of
the DB2Dictionary.java file, it's as if this latest commit is the only
record of the file. But, when I look at previous revisions, the file does
exist. It's as if, the commit operation did a replace instead of an update
commit. I wasn't aware that this operation was even possible. I guess we
need to hear from Dave as to what operation he did to accidentally cause
this to happen.
Kevin
On 2/21/07, Patrick Linskey [EMAIL PROTECTED] wrote:
I don't get it. wasn't there already an
openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.jav
a?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
-Original Message-
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 5:03 PM
To: open-jpa-commits@incubator.apache.org
Subject: svn commit: r510336 -
/incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache
/openjpa/jdbc/sql/DB2Dictionary.java
Author: wisneskid
Date: Wed Feb 21 17:03:06 2007
New Revision: 510336
URL: http://svn.apache.org/viewvc?view=revrev=510336
Log:
DB2 Optimize for clause enhancement
Added:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java
Added:
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=autorev=510336
==
---
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java (added)
+++
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java Wed Feb 21 17:03:06 2007
@@ -0,0 +1,210 @@
+/*
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in
writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
express or implied.
+ * See the License for the specific language governing
permissions and
+ * limitations under the License.
+ */
+package org.apache.openjpa.jdbc.sql;
+
+import java.sql.Connection;
+import java.sql.DatabaseMetaData;
+import java.sql.SQLException;
+import java.util.Arrays ;
+
+import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
+import org.apache.openjpa.jdbc.schema.Sequence;
+
+/**
+ * Dictionary for IBM DB2 database.
+ */
+public class DB2Dictionary
+extends AbstractDB2Dictionary {
+
+public DB2Dictionary() {
+platform = DB2;
+validationSQL = SELECT DISTINCT(CURRENT TIMESTAMP) FROM
++ SYSIBM.SYSTABLES;
+supportsSelectEndIndex = true;
+optimizeClause =optimize for;
+nextSequenceQuery = VALUES NEXTVAL FOR {0};
+
+sequenceSQL = SELECT SEQSCHEMA AS SEQUENCE_SCHEMA,
++ SEQNAME AS SEQUENCE_NAME FROM SYSCAT.SEQUENCES;
+sequenceSchemaSQL = SEQSCHEMA = ?;
+sequenceNameSQL = SEQNAME = ?;
+characterColumnSize = 254;
+
+binaryTypeName = BLOB(1M);
+longVarbinaryTypeName
Re: svn commit: r510281 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-persistence/src/main/java
3. OpenJPA does support a means of passing Oracle hints along through to the DBDictionary. Should we be trying to reuse some of the capabilities here? +1 4. In the following snippets, I'd rather if we used 'Integer.valueOf (1)' or, better yet, a symbolic constant, instead of creating new integer all the time. +fetch.setHint(openjpa.hint.optimize, new Integer(1)); + _query.getFetchConfiguration(). + setHint(openjpa.hint.optimize, new Integer(1)); Use serp.util.Numbers.valueOf(x). But actually I think both of these calls have to be more thoroughly re-thought. The FetchConfiguration is around for the life of the Broker/Query, and you're setting a hint on it that only applies to the very next call. What about all the other uses of the Broker or possible other executions of the Query? 5. I don't like the name 'openjpa.hint.optimize', as it's a bit ambiguous as to what's being optimized. I don't really know what 'optimize for' does, so I'm just guessing here, but how about 'openjpa.ExpectedRecordCount'? +1 But should be openjpa.hint.XXX -- see OracleDictionary.SELECT_HINT. I think we should move all this to a SelectExecutor.ExpectedResultCount property. It could replace the current Union.isSingleResult property. The user can set an expected result count via the Query hint API, and it will get set into the Select. In cases where a query range is set the property will return the max - min of the range. And in cases where we know there's only one result like find() calls (actually JDBCStoreManager.load) we can use the property directly internally. The DBDictionary can then ask the Select for the expected count and do what it wants with it when creating the SQL. ___ 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: r510336 - /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java
Okay, I think we need to back out these last two changes and revert back to revision 509885. Dave needs to go back to the drawing board for this db2 optimization change, probably create a JIRA report for this proposed change, and use the design discussion associated with the JIRA process to get the proper fix in place. +1 ___ 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: r510336 - /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java
+1. FTR, despite Abe's and my barrage of design suggestions, I love the optimization. Abe: good call on using it for ranged queries. -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: Abe White Sent: Thursday, February 22, 2007 8:07 AM To: open-jpa-dev@incubator.apache.org Subject: Re: svn commit: r510336 - /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache /openjpa/jdbc/sql/DB2Dictionary.java Okay, I think we need to back out these last two changes and revert back to revision 509885. Dave needs to go back to the drawing board for this db2 optimization change, probably create a JIRA report for this proposed change, and use the design discussion associated with the JIRA process to get the proper fix in place. +1 __ _ 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: RE: Howto integrate JPA within EJB2.1 session beans? [architecture]
If I understand it correct, I just have to bind the EMF onserver startup like. context.bind(my/jndi/name/for/emf,myEMFVariable); Yep. //does the statement below again create a NEW EMF or ist this //just a lookup in the jndi-tree? but why is it called Create //and not get? EntityManagerFactory emf = OpenJPAPersistence .createEntityManagerFactory( your/EMF/JNDI/location, (Context) null); It's just a lookup. I'm not sure why it's called 'create'. Anyone? //why do I have to create a new broker/entitymanager this way? //is this because I have to synchronize the SLSBs transaction //context with the newly created entitymanager? Yes -- our current OpenJPAPersistence EM lookup methods all create new EMs. The broker code will look up one associated with the current transaction, which is what you're looking for. Unfortunately, that means that we're using a synchronized block during the lookup. If it looks like EM lookup is a scalability issue for your app, do let us know -- it would be pretty straightforward to replace the synchronized block with a concurrent map. So if understand that right I just would have to call PersistenceService.getEntitymanager(); in every SLSB method (NOT in ejbCreate) when needed? fine. Yep. I really appreciate your help - it's quite complex to integrate JPA into an existing Java2EE 1.4 AppServer environment.. *puh* Yes -- sorry about that. We should at least be creating better-designed helper methods in OpenJPA to help out with this. One alternative, of course, is to use Spring 2, which does a pretty good job of JPA bootstrapping. -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: Hans Prueller [mailto:[EMAIL PROTECTED] Sent: Thursday, February 22, 2007 4:36 AM To: open-jpa-dev@incubator.apache.org; open-jpa-dev@incubator.apache.org Subject: Re: RE: Howto integrate JPA within EJB2.1 session beans? [architecture] Patrick, thank you for that tip. To be true, I was not aware of lifecycle related problems between my SLSBs and JPA - thank you for that hint. As I want to avoid working with ThreadLocal (simply because I didn't work with ThreadLocals yet) I would prefer the JNDI-EMF based approach. If I understand it correct, I just have to bind the EMF onserver startup like. context.bind(my/jndi/name/for/emf,myEMFVariable); I would be interested what the code for the PersistenceService class does: //does the statement below again create a NEW EMF or ist this //just a lookup in the jndi-tree? but why is it called Create //and not get? EntityManagerFactory emf = OpenJPAPersistence .createEntityManagerFactory( your/EMF/JNDI/location, (Context) null); //why do i have to cast the EMF to a brokerfactory now? I //would guess the broker is something like a more abstract //concept of entitymanager(factory)? //why do I have to create a new broker/entitymanager this way? //is this because I have to synchronize the SLSBs transaction //context with the newly created entitymanager? BrokerFactory bf = OpenJPAPersistence.cast(emf); Broker b = bf.newBroker( bf.getConfiguration().getConnectionUserName(), bf.getConfiguration().getConnectionPassword(), true, // the broker is part of a JTA managed tx bf.getConfiguration().getConnectionRetainModeConstant(), true); // look for an existing Broker on the tx broker.setAutoDetach(AutoDetach.DETACH_CLOSE, true); broker.setAutoDetach(AutoDetach.DETACH_ROLLBACK, true); broker.setDetachedNew(false); return OpenJPAPersistence.toEntityManager(b); } So if understand that right I just would have to call PersistenceService.getEntitymanager(); in every SLSB method (NOT in ejbCreate) when needed? fine. I really appreciate your help - it's quite complex to integrate JPA into an existing Java2EE 1.4 AppServer environment.. *puh* regards Hans Original-Nachricht Datum: Wed, 21 Feb 2007 08:43:20 -0800 Von: Patrick Linskey [EMAIL PROTECTED] An: open-jpa-dev@incubator.apache.org CC: Betreff: RE: Howto integrate JPA within EJB2.1 session beans? [architecture] Another common
Re: svn commit: r510336 - /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java
Thanks for the confirmation of the optimization ideas. We'll work through the issues and come back with another version. On 2/22/07, Patrick Linskey [EMAIL PROTECTED] wrote: +1. FTR, despite Abe's and my barrage of design suggestions, I love the optimization. Abe: good call on using it for ranged queries. -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: Abe White Sent: Thursday, February 22, 2007 8:07 AM To: open-jpa-dev@incubator.apache.org Subject: Re: svn commit: r510336 - /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache /openjpa/jdbc/sql/DB2Dictionary.java Okay, I think we need to back out these last two changes and revert back to revision 509885. Dave needs to go back to the drawing board for this db2 optimization change, probably create a JIRA report for this proposed change, and use the design discussion associated with the JIRA process to get the proper fix in place. +1 __ _ 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.
[jira] Updated: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-151: -- Attachment: diff.txt Prposed changes to remove pcFlags from enhanced classes i. remove pcFlags related interface method from PersistenceCapable and StateManager ii. remove pcFlags related code generation from PCEnhancer Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions. - Key: OPENJPA-151 URL: https://issues.apache.org/jira/browse/OPENJPA-151 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Attachments: diff.txt Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant. This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation: 1. class A has one-to-one relation to class B 2. an instance a of A is related to b1 of B. b2 is another instance of B. 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*. 4. in the remote process a* is associated with b2* 5. a* is merged to the original process. The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade. The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty. Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-158) OpenJPA logs overly-verbose at INFO level
[ https://issues.apache.org/jira/browse/OPENJPA-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475095 ] Dain Sundstrom commented on OPENJPA-158: +1 With this change I will be able to lower the log level in OpenEJB to INFO. Currently it is set to WARN due to the extreme number of messages you get from even a small JPA application. OpenJPA logs overly-verbose at INFO level - Key: OPENJPA-158 URL: https://issues.apache.org/jira/browse/OPENJPA-158 Project: OpenJPA Issue Type: Improvement Reporter: Patrick Linskey OpenJPA currently outputs rather a lot of INFO-level messages, especially when using runtime enhancement. It would be nice to quiet things down a bit. In particular, the following statements from a 'mvn package' run seem TRACE-worthy: 0 test INFO [main] openjpa.MetaData - Found 2 classes with metadata in 0 milliseconds. 0 test INFO [main] openjpa.MetaData - Parsing class org.apache.openjpa.persistence.query.ManyOneEntity. 0 test INFO [main] openjpa.MetaData - Parsing package org.apache.openjpa.persistence.query.ManyOneEntity. 10 test INFO [main] openjpa.MetaData - Parsing class org.apache.openjpa.persistence.query.ManyOneEntitySub. 10 test INFO [main] openjpa.jdbc.Schema - Reading table information for schema name null, table name ManyOneEntity. 10 test INFO [main] openjpa.jdbc.Schema - Reading table information for schema name null, table name OPENJPA_SEQUENCE_TABLE. 10 test INFO [main] openjpa.jdbc.Schema - Reading sequence information for schema null, sequence name null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[
https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475099
]
Pinaki Poddar commented on OPENJPA-151:
---
Why will this require re-enhancement?
==
Previous enhancement:
private static final void pcSetdepartment(Employee employee, Department
department1) {
if(employee.pcFlags == 0) {
employee.department = department1;
return;
}
if(employee.pcStateManager == null) {
employee.department = department1;
return;
} else {
employee.pcStateManager.settingObjectField(employee,
pcInheritedFieldCount + 0, employee.department, department1, 0);
return;
}
}
Enhanced version once pcFlags is removed:
private static final void pcSetdepartment(Employee employee, Department
department1) {
if(employee.pcStateManager == null) {
employee.department = department1;
return;
} else {
employee.pcStateManager.settingObjectField(employee,
pcInheritedFieldCount + 0, employee.department, department1, 0);
return;
}
}
==
If the previous enhanced version is used, the behaviour of serialized domain
class will remain unchanged even with new OpenJPA runtime (i.e. PC/SM
interfaces without calling back on pcReplaceFlags()).
But all this optimization to short-circuit StateManager mediation is only
happening with JDO facade that too when the accessed field in not in default
fetch group.
Added field in enhanced vesrion of a class is not serialized. Hence the
change in detached+serialized instances is not registered under certain
conditions.
-
Key: OPENJPA-151
URL: https://issues.apache.org/jira/browse/OPENJPA-151
Project: OpenJPA
Issue Type: Improvement
Components: kernel
Reporter: Pinaki Poddar
Assigned To: Pinaki Poddar
Attachments: diff.txt
Enhancement adds a transient byte member field pcFlags to the class. This
field is originally used to optimize field access/mutation i.e. to
short-circuit mediation via StateManager under certain conditions (e.g. when
the field is part of the default fetch group). The field is transient,
perhaps, to maintain serialization compatibility. However, later changes such
as DetachedStateManager and improved attach strategies have made the usage of
these flag redundant.
This issue is a proposal to remove this field from the enhanced classes. The
proposed change is initiated by the following observation:
1. class A has one-to-one relation to class B
2. an instance a of A is related to b1 of B. b2 is another instance of B.
3. a, b1, b2 are detached, serialized, transported over the wire, desrialized
in a remote process as a*, b1* and b2*.
4. in the remote process a* is associated with b2*
5. a* is merged to the original process.
The change is not persisted when OpenJPA kernel is used with a JDO facade. It
works with JPA facade.
The initial analysis shows that the reason can be attributed to pcFlags and
the optimization in enhanced classes based on to its value. Because pcFlags
is not
serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of
a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the
detached version was carrying its own StateManager). While merging the
instance a* back, it was adjudged clean while actually it was dirty. In JPA
facade, the enhancement process did not add the extra optimization for setter
and so the cloned owner instance was righly marked dirty.
Please note that if this proposal is accepted by the community, it will
require reenhancement of existing domain classes. The change will impact the
internal StateManager and PersistenceCapable API (essentally removal of
certain methods than any other behavioural change).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475100 ] Patrick Linskey commented on OPENJPA-151: - Maybe we should do something explicit to make sure that classes enhanced with the old enhancer can't load anymore. It sounds like currently, classes will just silently start to behave differently. Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions. - Key: OPENJPA-151 URL: https://issues.apache.org/jira/browse/OPENJPA-151 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Attachments: diff.txt Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant. This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation: 1. class A has one-to-one relation to class B 2. an instance a of A is related to b1 of B. b2 is another instance of B. 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*. 4. in the remote process a* is associated with b2* 5. a* is merged to the original process. The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade. The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty. Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475102 ] Michael Dick commented on OPENJPA-160: -- Another performance issue we've run into is the overhead of creating a new BrokerImpl object when the application calls createEntityManager. The JPA spec clearly states that the provider needs to return a new EntityManager instance, and we're not trying to circumvent that requirement. However it seems plausible that we could reuse the underlying BrokerImpl object, once all the persistence data has been cleared (ie after BrokerImpl.free has been called). Implementing a fairly simple object reuse pool resulted in a significant performance improvement in our testing. I don't see this as being a violation of the intent of the spec, but I'd rather get a sense of consensus before I/we go any further. Questions : 1. Is there a reason why we can't reuse the BrokerImpl objects? 2. Assuming we can reuse the objects, where should we put the reuse pool? The original implementation created a static map in AbstractBrokerFactory. I'm not sure that's the best place for it though. BrokerImpl isn't a final class it's possible that different configurations could use different broker implementations (through the broker plugin). Maybe we need a new plugin which indicates that class to use as a Broker pool? 3. Should we pool the broker instances by default? I think we'll want this to be configurable, but I'm not sure it needs to be on by default. Justification : We've been running tests with the Sun Application Server and adding in a BrokerImpl reuse pool brings the performance on par with Hibernate. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475108 ] Patrick Linskey commented on OPENJPA-160: - 1. Is there a reason why we can't reuse the BrokerImpl objects? Architecturally, none that I can think of. But we should take care to ensure that BrokerImpl.free() really does enough work to close up resources appropriately. Also, I'd love to take a look at some profiling data to see if we can just optimize creation of brokers instead of adding the complexity of a pool. 2. Assuming we can reuse the objects, where should we put the reuse pool? The original implementation created a static map in AbstractBrokerFactory. I'm not sure that's the best place for it though. BrokerImpl isn't a final class it's possible that different configurations could use different broker implementations (through the broker plugin). Maybe we need a new plugin which indicates that class to use as a Broker pool? The two options that I see are a Configuration option and a non-static field in AbstractBrokerFactory. I think that I prefer making it an OpenJPAConfiguration option, so that it's more easily configurable. Configuration would look like so: property name=openjpa.BrokerPool value=Size=50/ If BrokerImpl.free() purges the data passed in to the newBroker() call, then we should be able to just use a set. In this scenario, the newBroker() code would then grab something from the set, populate the obtained broker with the data passed into the newBroker() call, and return it. If BrokerImpl.free() leaves the broker in a state where the data passed into newBroker() is relevant, then we should create a key (probably a private inner class) that includes that data in it, and maintain a map of sets, keyed off of that data. All things equal, I'd prefer if we could use a Set (the first case). 3. Should we pool the broker instances by default? I think we'll want this to be configurable, but I'm not sure it needs to be on by default. We should use the pooling logic, but allow the user to control the pool size. If this is a performance benefit, then we should choose some reasonable initial pool size. I have no idea what 'reasonable' is. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475144 ] Pinaki Poddar commented on OPENJPA-151: --- One way is to add some extra checks on isPersistenceCapable() for the deprecated pcFlags() method and warn if the enhanced version is old. Or is that too arbitrary? Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions. - Key: OPENJPA-151 URL: https://issues.apache.org/jira/browse/OPENJPA-151 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Attachments: diff.txt Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant. This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation: 1. class A has one-to-one relation to class B 2. an instance a of A is related to b1 of B. b2 is another instance of B. 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*. 4. in the remote process a* is associated with b2* 5. a* is merged to the original process. The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade. The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty. Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
possible to write a JPA Query to that filters both an Entity and its relationship entities?
Hi there, I have a question about JPA Queries containing relationships and a WHERE filter. I basically want to have a JSF page containing a datatable that shows a list of Departments - each Department row shows relevant columns (department name, ID, etc) as well as a nested list of that Department's Employees with 15 or more years of service. I was wondering if there was any way to create a JPA query that would return me such a result using just a single query. From what I have heard, I don't believe this is possible but thought I'd ask here just to be sure. As far as I know, JPA will just return me the Departments that match that query and each Department will contain every Employee that belongs to it. Background: I have a DEPARTMENT entity with a one-to-many relationship to an EMPLOYEE entity. On my web page, I want to display departments with a department number = 100 and containing EMPLOYEES with more than 15 years of service. Using SDOs I was able to write a query that would return a List of results which I would then bind to my JSF datatable. This list would contain Departments, and the Departments would have the Employees that matched that criteria. To do something similar in JPA, I think I now need to do n + 1 queries. That is, one query to retrieve the departments that I want to display, and then for each department another query to get the filtered list of its Employees. In summary, I basically want to do something like: select d from Department d LEFT JOIN d.employeeCollection e WHERE d.deptno = 100 AND e.yearsOfService = 15 But I think I need to do two separate queries. One to get the departments: select d from Department d WHERE d.deptno = 100 Then for each Department returned in that result set, a separate query to get the employees I'm after: select e from Employee e where e.department.deptno = d.deptno and e.yearsOfService = 15 Does this sound like the right/only way to do this? Thanks, Tom
[jira] Updated: (OPENJPA-94) Allow MappingTool and persistence.xml to support drop-create for database schema
[ https://issues.apache.org/jira/browse/OPENJPA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sherry Shen updated OPENJPA-94: --- Attachment: openjpa_94.zip Test case with README and test results. Allow MappingTool and persistence.xml to support drop-create for database schema Key: OPENJPA-94 URL: https://issues.apache.org/jira/browse/OPENJPA-94 Project: OpenJPA Issue Type: New Feature Reporter: Shay Banon Attachments: openjpa_94.zip Currently, in the persistence context, one can define: property name=openjpa.jdbc.SynchronizeMappings value=buildSchema / Which causes OpenJPA to build the database schema based on the mapping defined. Currently, there is no way to define it to drop tables if they exists before creating the database schema. This is very useful for tests that drop (if exists) and creates new tables for each test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475155 ] Patrick Linskey commented on OPENJPA-151: - Another would be to add a new getEnhancementContractVersion() method to the PersistenceCapable interface. This would cause immediate breakage of the old classes, since they don't have that method, and allow us to detect other subtle behavior changes in the future by checking that the version is compatible. Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions. - Key: OPENJPA-151 URL: https://issues.apache.org/jira/browse/OPENJPA-151 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Attachments: diff.txt Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant. This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation: 1. class A has one-to-one relation to class B 2. an instance a of A is related to b1 of B. b2 is another instance of B. 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*. 4. in the remote process a* is associated with b2* 5. a* is merged to the original process. The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade. The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty. Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-161) Overuse of synchronization in AbstractBrokerFactory
Overuse of synchronization in AbstractBrokerFactory --- Key: OPENJPA-161 URL: https://issues.apache.org/jira/browse/OPENJPA-161 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Patrick Linskey AbstractBrokerFactory maintains a MapTransaction,ListBroker that is guarded by synchronized blocks. These synchronized blocks should be removed if possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-151: -- Attachment: PCEnhancer.AddVersion.Diff.txt Added a public int getEnhancementContractVersion() to all enhanced classes. Please review these baby steps into bytecode manipulation. The diff also contains removal of pcFlags related changes. It does not include the change in PersistenceCapable interface. 1. Should the method be static? 2. The ENHANCER_VERSION is public static final in PCEnhncer. So the user can: PersistenceCapable pc = ... if (pc.getEnhancementContractVersion() PCEnhancer.ENHANCER_VERSION) // warn or throw exception 3. What is a good central location to add the above check? Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions. - Key: OPENJPA-151 URL: https://issues.apache.org/jira/browse/OPENJPA-151 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Attachments: diff.txt, PCEnhancer.AddVersion.Diff.txt Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant. This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation: 1. class A has one-to-one relation to class B 2. an instance a of A is related to b1 of B. b2 is another instance of B. 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*. 4. in the remote process a* is associated with b2* 5. a* is merged to the original process. The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade. The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty. Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: RE: Howto integrate JPA within EJB2.1 session beans? [architecture]
Unfortunately, that means that we're using a synchronized block during the lookup. If it looks like EM lookup is a scalability issue for your app, do let us know -- it would be pretty straightforward to replace the synchronized block with a concurrent map. OK, I got fed up with that synchronized block. OPENJPA-161 tracks the issue; I've got a patch that I'll submit once some more eyes look at it. -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: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: Thursday, February 22, 2007 8:38 AM To: open-jpa-dev@incubator.apache.org Subject: RE: RE: Howto integrate JPA within EJB2.1 session beans? [architecture] If I understand it correct, I just have to bind the EMF onserver startup like. context.bind(my/jndi/name/for/emf,myEMFVariable); Yep. //does the statement below again create a NEW EMF or ist this //just a lookup in the jndi-tree? but why is it called Create //and not get? EntityManagerFactory emf = OpenJPAPersistence .createEntityManagerFactory( your/EMF/JNDI/location, (Context) null); It's just a lookup. I'm not sure why it's called 'create'. Anyone? //why do I have to create a new broker/entitymanager this way? //is this because I have to synchronize the SLSBs transaction //context with the newly created entitymanager? Yes -- our current OpenJPAPersistence EM lookup methods all create new EMs. The broker code will look up one associated with the current transaction, which is what you're looking for. Unfortunately, that means that we're using a synchronized block during the lookup. If it looks like EM lookup is a scalability issue for your app, do let us know -- it would be pretty straightforward to replace the synchronized block with a concurrent map. So if understand that right I just would have to call PersistenceService.getEntitymanager(); in every SLSB method (NOT in ejbCreate) when needed? fine. Yep. I really appreciate your help - it's quite complex to integrate JPA into an existing Java2EE 1.4 AppServer environment.. *puh* Yes -- sorry about that. We should at least be creating better-designed helper methods in OpenJPA to help out with this. One alternative, of course, is to use Spring 2, which does a pretty good job of JPA bootstrapping. -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: Hans Prueller [mailto:[EMAIL PROTECTED] Sent: Thursday, February 22, 2007 4:36 AM To: open-jpa-dev@incubator.apache.org; open-jpa-dev@incubator.apache.org Subject: Re: RE: Howto integrate JPA within EJB2.1 session beans? [architecture] Patrick, thank you for that tip. To be true, I was not aware of lifecycle related problems between my SLSBs and JPA - thank you for that hint. As I want to avoid working with ThreadLocal (simply because I didn't work with ThreadLocals yet) I would prefer the JNDI-EMF based approach. If I understand it correct, I just have to bind the EMF onserver startup like. context.bind(my/jndi/name/for/emf,myEMFVariable); I would be interested what the code for the PersistenceService class does: //does the statement below again create a NEW EMF or ist this //just a lookup in the jndi-tree? but why is it called Create //and not get? EntityManagerFactory emf = OpenJPAPersistence .createEntityManagerFactory( your/EMF/JNDI/location, (Context) null); //why do i have to cast the EMF to a brokerfactory now? I //would guess the broker is something like a more abstract //concept of entitymanager(factory)? //why do I have to create
Re: possible to write a JPA Query to that filters both an Entity and its relationship entities?
What about something like: select distinct e.department from employee e where e.department.deptno =100 and e.yearsOfService=15 Not sure if the above will do the trick without trying it myself... Dain Sundstrom wrote: I'm no JPA expert, so take my comments with a grain of salt. How about searching the other direction: select e from employee e where e.department.depno = 100 e.yearsOfService = 15 Then assuming OpenJPA can do it, you could tune the query to grab the department object along with the employee. If OpenJPA can't do that, you will get at most 100+1 queries. Alternatively, you could try executing this query before the one above: select d from Department d WHERE d.deptno = 100 And then rely on the OpenJPA cache to hook the departments to the employees. Depending on the database vendor and the data in the tables, executing two queries may be more efficient then one. -dain On Feb 22, 2007, at 12:21 PM, Tom Mutdosch wrote: Hi there, I have a question about JPA Queries containing relationships and a WHERE filter. I basically want to have a JSF page containing a datatable that shows a list of Departments - each Department row shows relevant columns (department name, ID, etc) as well as a nested list of that Department's Employees with 15 or more years of service. I was wondering if there was any way to create a JPA query that would return me such a result using just a single query. From what I have heard, I don't believe this is possible but thought I'd ask here just to be sure. As far as I know, JPA will just return me the Departments that match that query and each Department will contain every Employee that belongs to it. Background: I have a DEPARTMENT entity with a one-to-many relationship to an EMPLOYEE entity. On my web page, I want to display departments with a department number = 100 and containing EMPLOYEES with more than 15 years of service. Using SDOs I was able to write a query that would return a List of results which I would then bind to my JSF datatable. This list would contain Departments, and the Departments would have the Employees that matched that criteria. To do something similar in JPA, I think I now need to do n + 1 queries. That is, one query to retrieve the departments that I want to display, and then for each department another query to get the filtered list of its Employees. In summary, I basically want to do something like: select d from Department d LEFT JOIN d.employeeCollection e WHERE d.deptno = 100 AND e.yearsOfService = 15 But I think I need to do two separate queries. One to get the departments: select d from Department d WHERE d.deptno = 100 Then for each Department returned in that result set, a separate query to get the employees I'm after: select e from Employee e where e.department.deptno = d.deptno and e.yearsOfService = 15 Does this sound like the right/only way to do this? Thanks, Tom
Re: possible to write a JPA Query to that filters both an Entity and its relationship entities?
How about select dept, oldtimers from Department dept LEFT JOIN dept.employeeCollection oldtimers WHERE dept.deptno = 100 AND oldtimers.yearsOfService = 15 That should give you only departments that satisfy the deptno constraint and since you are not using outer join, only departments that also have at least one employee satisfying the yearsOfService constraint. The results would have one element for each employee. Each result row would contain the department and the employee. So you would have the results: [looks better in monospace font] deptoldtimers = == RD Larry RD Curly RD Moe Entertainment Fred Entertainment Ginger Craig On Feb 22, 2007, at 12:21 PM, Tom Mutdosch wrote: Hi there, I have a question about JPA Queries containing relationships and a WHERE filter. I basically want to have a JSF page containing a datatable that shows a list of Departments - each Department row shows relevant columns (department name, ID, etc) as well as a nested list of that Department's Employees with 15 or more years of service. I was wondering if there was any way to create a JPA query that would return me such a result using just a single query. From what I have heard, I don't believe this is possible but thought I'd ask here just to be sure. As far as I know, JPA will just return me the Departments that match that query and each Department will contain every Employee that belongs to it. Background: I have a DEPARTMENT entity with a one-to-many relationship to an EMPLOYEE entity. On my web page, I want to display departments with a department number = 100 and containing EMPLOYEES with more than 15 years of service. Using SDOs I was able to write a query that would return a List of results which I would then bind to my JSF datatable. This list would contain Departments, and the Departments would have the Employees that matched that criteria. To do something similar in JPA, I think I now need to do n + 1 queries. That is, one query to retrieve the departments that I want to display, and then for each department another query to get the filtered list of its Employees. In summary, I basically want to do something like: select d from Department d LEFT JOIN d.employeeCollection e WHERE d.deptno = 100 AND e.yearsOfService = 15 But I think I need to do two separate queries. One to get the departments: select d from Department d WHERE d.deptno = 100 Then for each Department returned in that result set, a separate query to get the employees I'm after: select e from Employee e where e.department.deptno = d.deptno and e.yearsOfService = 15 Does this sound like the right/only way to do this? Thanks, Tom 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
