Re: Can @JoinTable be used in combination with @ManyToOne?
Can I map a many to one association through a join table (association table)? You can't use a join table, but you can put your many-one foreign key column(s) in a secondary table, which amounts to the same thing. ___ 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: How to turn off sub-selects in updates?
On 3/12/07, Patrick Linskey [EMAIL PROTECTED] wrote: What is the JPQL query that you're issuing that is resulting in that SQL statement? One easy way to get this information is by setting the 'Query' log channel to TRACE. This is the query that caused the above trace. DELETE FROM WeblogEntryTagAggregateData w WHERE w.weblog = ?1 - Dave
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
I opened a JIRA feature openjpa-168 to discuss how to improve this. On 2/27/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, What's the word on this issue? -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 Sent: Wednesday, February 21, 2007 3:07 PM To: 'open-jpa-dev@incubator.apache.org' Subject: 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/org/apache/openjpa/persistence/ Some comments: 1. What does optimize for n do? Do you have a link where I could read up on it? 2. Is there equivalent magic for other databases? 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? 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)); 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'? 6. How does the user access this from JPQL queries when they don't want to use a getSingleResult() call? Will it work to use the JPA query hint facilities, or do they have to use the broker APIs? Do we even care, since they could just use getSingleResult()? Maybe it's better to not allow this to be user-configurable, if we can always infer the right setting. But I'm guessing that sometimes the user might want to say that they expect 10 results or something like that 7. It seems like this could also be useful for when a one-to-one or a many-to-one is traversed. -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 2:50 PM To: open-jpa-commits@incubator.apache.org Subject: 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/org/apache/openjpa/persistence/ Author: wisneskid Date: Wed Feb 21 14:50:04 2007 New Revision: 510281 URL: http://svn.apache.org/viewvc?view=revrev=510281 Log: DB2 Optimize for clause enhancement Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/DB2Dictionary.java incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/ openjpa/jdbc/sql/DBDictionary.java incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apach e/openjpa/kernel/BrokerImpl.java incubator/openjpa/trunk/openjpa-persistence/src/main/java/org/ apache/openjpa/persistence/QueryImpl.java 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.ja va? view=diffrev=510281r1=510280r2=510281 == --- 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 Wed Feb 21 14:50:04 2007 @@ -20,6 +20,7 @@ import java.sql.SQLException; import java.util.Arrays; +import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
[jira] Commented: (OPENJPA-168) sql optimize n rows query hint
[ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480177 ] Abe White commented on OPENJPA-168: --- 1. I think the hint name should be more like openjpa.hint.OptimizeResultCount. It should be hint and not hints to match the existent openjpa.hint.OracleSelectHint. And I see no reason to tie it to SQL. 2. I don't think we need a FetchConfiguration instance variable. For find() calls and loading hollow objects we always know we're only loading one instance because we use the StoreManager.load() call internally. There are similar internal APIs used only when traversing a to-one relation. So the JDBCStoreManager or relation field strategies can set the proper expected result count into the Select directly. Much better than having to set a FetchConfiguration value and then make sure it disappears for subsequent selects. The only problem is Query.getSingleResult, because right now we execute the query as a multi-result query and then extract the one result at the JPA layer. We don't have to do it this way, though. The underlying kernel Query already has a Unique property you can set to indicate a single result. The property doesn't have quite the semantics we want, because it allows a query that returns 0 results whereas that's an error in JPA. We can't just change the Unique semantics because of JDO, but we could certainly make it configurable on the Query instance whether a Unique query can legally return 0 results. So if we start using the Unique property rather than extracting the single result at the JPA layer, we'll know when the user is using getSingleResult when we construct the Select, and we can again set the expected number of results directly into the Select. 3. The SelectImpl already knows when it has to-many eager joins; no need for additional state. See SelectImpl.hasEagerJoin(boolean toMany). 4. getOptimizeClause seems too generic. I'm also not clear on what use it has in the base DBDictionary class if you state that individual dictionaries will still have to override toSelect themselves to insert the optimization SQL. sql optimize n rows query hint -- Key: OPENJPA-168 URL: https://issues.apache.org/jira/browse/OPENJPA-168 Project: OpenJPA Issue Type: New Feature Reporter: David Wisneski Assigned To: David Wisneski There werre various comments from Patrick, Abe and Kevin Sutter about the code that I checked related to Optimize hint. So I have gone back and relooked at this and wil be making some changes. At Kevin's suggestion I will do this through a JIRA feature so that folks will have opportunity to comment on this before the code is actually done and checked in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-169) Queries against dirty extents and flushing: should provide an option to set savepoint, flush, query, rollback to savepoint
Queries against dirty extents and flushing: should provide an option to set savepoint, flush, query, rollback to savepoint -- Key: OPENJPA-169 URL: https://issues.apache.org/jira/browse/OPENJPA-169 Project: OpenJPA Issue Type: Improvement Reporter: Patrick Linskey When issuing a JPQL query after changing data that is involved in the access path of the query, OpenJPA must either flush before querying (and therefore obtain a Connection), or load all instances of the potentially-dirty classes into memory and evaluate the query in memory. Now that OpenJPA supports savepoints, we should provide an option to set savepoint, flush, query, and then roll the savepoint back. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-170) Constrain types to be flushed
Constrain types to be flushed - Key: OPENJPA-170 URL: https://issues.apache.org/jira/browse/OPENJPA-170 Project: OpenJPA Issue Type: Improvement Reporter: Patrick Linskey When invoking EntityManager.flush(), all dirty instances are flushed. This can be inconvenient when working in an application with multiple distinct modules that may need to flush for query purposes. OpenJPA should provide an OpenJPAEntityManager.flush(Class... classesToFlush) API that limits the flushes to just the specified classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
OpenJPA love
Hi guys, Just a quick note to let you know we've completed the migration of Apache ODE from Hibernate to OpenJPA. Everything seem to work pretty well now. I expect a few glitches here and there as we run in heavily parallelized environments but the transition has been pretty smooth. Thanks a lot for your help and all the good work! The ODE team.
