[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dick updated OPENJPA-182:
-
Fix Version/s: 0.9.7
> db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS
> ---
Messieurs-dames,
As I could not find much clues about the right way to do it, here I come:
I'm trying to get an EntityManagerFactory properly setup from the
Persistence class, but I cannot get further than the following exception
javax.persistence.PersistenceException: No Persistence provider fo
Messieurs-dames,
As I could not find much clues about the right way to do it, here I come:
I'm trying to get an EntityManagerFactory properly setup from the
Persistence class, but I cannot get further than the following exception
javax.persistence.PersistenceException: No Persistence provider fo
Hi Erwan,
What do you have in persistence.xml?
It should contain something like this :
http://java.sun.com/xml/ns/persistence";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
version="1.0">
. . .
One thing to watch out for is if you've defined a provider inside the
p
I added OpenJPA-182 to the change log & release notes. I'm assuming we can
close the JIRA (re-targeted for 0.9.7) and then start the release. I'm
going to go ahead and create the branch this morning, but I'll hold off on
the vote until everyone is happy with OpenJPA-182.
On 4/6/07, [EMAIL PROTEC
Comments inline...
> +/**
> + * The isolation level for queries issued to the database.
> This overrides
> + * the persistence-unit-wide
> openjpa.jdbc.TransactionIsolation
> + * value.
> + *
> + * Must be one of [EMAIL PROTECTED] Connection#TRANSACTION_NONE},
> + *
Messieurs-dames,
As I could not find much clues about the right way to do it, here I come:
I'm trying to get an EntityManagerFactory properly setup from the
Persistence class, but I cannot get further than the following exception
javax.persistence.PersistenceException: No Persistence provider fo
Key column does not cascade multiple joins.
---
Key: OPENJPA-206
URL: https://issues.apache.org/jira/browse/OPENJPA-206
Project: OpenJPA
Issue Type: Bug
Affects Versions: 0.9.7
Environment
[
https://issues.apache.org/jira/browse/OPENJPA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Anderson updated OPENJPA-206:
--
Attachment: FunInheritanceJavaPI.zip
> Key column does not cascade multiple joins.
> -
> Why is this setting called "IsolationLevel" where our global setting
> is called "TransactionIsolation"? Shouldn't this local setting just
> be called "Isolation" for consistency? Same with the
> FetchPlan facade.
Personally, I feel that 'IsolationLevel' is a more-well-known term for
the
> Note :
> I'm using a persistence.xml for single persitence unit
> creation, and this
> test works fine. I've had a dive into the source code, and found the
> provider is lookuped and found by the glassfish persistence
> implementation
> class. The exception is raised on the open jpa side, and I
Thank you for your time Patrik,
Actually the persistence.xml used in the META-INF jar in the CP points to
another persistence unit name.
The thing is -and I may be mistaking about this practice- I want to
programmatically my own persistence units, based on different name, at run
time, and I dunno
> Could you (or anyone else) confirm this last point?
Your are correct -- when using the Persistence class for bootstrapping,
you must provide a name of a persistence unit defined in XML.
To create an EMF programmatically in a standards-based way, you should
use the classes and interfaces in java
Patrick,
With your recent changes regarding the OPENJPA-182 The logic
has changed a little.What was intended was that if the forUpdate flag = true
we append the FOR UPDATE CLAUSE.But in case of DB2 if the forUpdate flag =
false then we append FOR READ ONLY clause.Now the FOR READ ONLY
Sorry, a correction. If you want to avoid the XML, you can't use the
PersistenceProvider.createEntityManagerFactory(String,Map) signature.
Instead, you must use
PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitI
nfo,Map).
One thing to bear in mind is that OpenJPA may optimize
Yes -- see my more recent commit. It should resolve this issue.
Once you guys get some unit tests in place for this, and we have DB2
coverage in our checkin tests, this type of thing shouldn't happen.
Does Derby provide the same support? IIRC, Derby shares quite a bit of
DB2 syntax; maybe you cou
Well thanks for this piece of inf, Patrick, I'll go with my impl.
Keep on opening JPA !
2007/4/6, Patrick Linskey <[EMAIL PROTECTED]>:
Sorry, a correction. If you want to avoid the XML, you can't use the
PersistenceProvider.createEntityManagerFactory(String,Map) signature.
Instead, you must us
Patrick,
Derby does not support this.And I am running on the most recent
code and still seeing same behaviour.Essentially for DB2 you cannot check
(forUpdate && !simulateLocking).DB2 will always have a forUpdate clause
whether forUpdae is true or false
On 4/6/07, Patrick Linskey <[EM
Gotcha. The attached patch should probably get around that problem; I
haven't tested it at all though. Let me know what happens in your
environment.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message
patch?
On 4/6/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
Gotcha. The attached patch should probably get around that problem; I
haven't tested it at all though. Let me know what happens in your
environment.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
hi pinaki,
should i file an issue for this one? i can attach the failing test case there.
thanks for your help.
jeff <[EMAIL PROTECTED]> wrote: Pinaki Poddar
wrote: > i can also pass along a maven2 project
Can you post the Java source of the test case and domain classes for us
to reproduce t
Also I wanted to make sure that if you want to turn off the forUpdate flag
do u say
qry.setHint("openjpa.FetchPlan.ReadLockMode", null)
because LockModeType is just READ or WRITE and in both the cases the flag is
turned on
On 4/6/07, Ritika Maheshwari <[EMAIL PROTECTED]> wrote:
patch?
On 4/
Patrick
I didn't get the patch
On 4/6/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
Gotcha. The attached patch should probably get around that problem; I
haven't tested it at all though. Let me know what happens in your
environment.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
Hi Jeff,
I could reproduce the error on your test case. So please file a JIRA
issue.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Friday, April 06, 2007 12:57 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite I
Hmm... that's odd. I just attached it to the JIRA issue.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsi
[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Linskey updated OPENJPA-182:
Attachment: OPENJPA-182.patch
Remove forUpdate from DBDictionary.toOperation()'s signature
> Also I wanted to make sure that if you want to turn off the
> forUpdate flag
> do u say
>
> qry.setHint("openjpa.FetchPlan.ReadLockMode", null)
>
> because LockModeType is just READ or WRITE and in both the
> cases the flag is
> turned on
I suggest you add a test case to the TestSelectForUpd
The patch seems to work fine now.I see FOR READ ONLY clauses
On 4/6/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
> Also I wanted to make sure that if you want to turn off the
> forUpdate flag
> do u say
>
> qry.setHint("openjpa.FetchPlan.ReadLockMode", null)
>
> because LockModeType is just R
[
https://issues.apache.org/jira/browse/OPENJPA-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-202.
---
Resolution: Fixed
Fix Version/s: 0.9.7
Changed detach process to never detach LRS fields. In
[
https://issues.apache.org/jira/browse/OPENJPA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487321
]
Abe White commented on OPENJPA-201:
---
Is the named table defined as a SecondaryTable anywhere? How is OpenJPA
sup
>> Why is this setting called "IsolationLevel" where our global setting
>> is called "TransactionIsolation"? Shouldn't this local setting just
>> be called "Isolation" for consistency? Same with the
>> FetchPlan facade.
>
> Personally, I feel that 'IsolationLevel' is a more-well-known term for
>
[
https://issues.apache.org/jira/browse/OPENJPA-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487324
]
Patrick Linskey commented on OPENJPA-202:
-
Another possibility would be to detach the field if it is explici
On 4/6/07, Abe White <[EMAIL PROTECTED]> wrote:
>> Why is this setting called "IsolationLevel" where our global setting
>> is called "TransactionIsolation"? Shouldn't this local setting just
>> be called "Isolation" for consistency? Same with the
>> FetchPlan facade.
>
> Personally, I feel tha
Hi,
There's one last open issue for OPENJPA-182 that I know of. Currently,
the JDBCFetchPlan.setIsolation() and
JDBCFetchConfiguration.setIsolation() methods use the symbolic constants
defined in Connection. Should they, or should we use our own?
I think that JDBCFetchPlan should take a Java 5 en
FWIW, my personal naming preference in descending order:
1. setTransactionIsolationLevel
2. setTransactionIsolation (user: "Is this a boolean? Of course I
want my transactions to be isolated!")
3. setIsolation (user: "What exactly is being 'isolated'? The
EntityManager or the cache or someth
Done in r526266.
-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
-1 to anything with 'transaction' in it. This is a per-query override
for the transaction isolation level, not a per-transaction setting.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together
FYI, one problem with using an enum is that the rest of FetchPlan uses
symbolic constants, not enums. But, I think that we should deprecate
those methods and add in enum-based methods there when applicable at
some point here, anyways.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_
[
https://issues.apache.org/jira/browse/OPENJPA-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Blatttman updated OPENJPA-207:
--
Attachment: book.zip
to run the test case, please start a derby network server on loca
failure when composite ID w/ another composite ID as a field
-
Key: OPENJPA-207
URL: https://issues.apache.org/jira/browse/OPENJPA-207
Project: OpenJPA
Issue Type: Bug
Affects
[
https://issues.apache.org/jira/browse/OPENJPA-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Blatttman updated OPENJPA-207:
--
Summary: failure when composite ID has another composite ID as a field
(was: failure
Adding in enum-based methods seems like a good idea to me.
There isn't much harm in starting here and finishing the rest of FetchPlan
later, so long as we do it someday.
On 4/6/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
FYI, one problem with using an enum is that the rest of FetchPlan uses
> I think that JDBCFetchPlan should take a Java 5 enum, and
> JDBCFetchConfiguration should use the Connection values.
Certainly JDBCFetchConfiguration should use the Connection values. I
personally have never had a problem with symbolic constants for
settings, but enums for the FetchPlan ar
[
https://issues.apache.org/jira/browse/OPENJPA-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Prud'hommeaux resolved OPENJPA-193.
Resolution: Fixed
Fix Version/s: (was: 0.9.8)
0.9.7
NoResultException and NonUniqueResultException are not thrown when expected
---
Key: OPENJPA-208
URL: https://issues.apache.org/jira/browse/OPENJPA-208
Project: OpenJPA
[
https://issues.apache.org/jira/browse/OPENJPA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487348
]
Marc Prud'hommeaux commented on OPENJPA-208:
This seems to have slipped in in the fix for OPENJPA-168: s
[
https://issues.apache.org/jira/browse/OPENJPA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487349
]
Marc Prud'hommeaux commented on OPENJPA-208:
This appears to have been introduced by the commits for the
[
https://issues.apache.org/jira/browse/OPENJPA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487352
]
Marc Prud'hommeaux commented on OPENJPA-208:
The change to OPENJPA-168 seems to have been done to make t
Query returning 2 entities w/unidir 1-1 relationship gets
openjpa.persistence.ArgumentException: Address with the same id already exists
in the L1 cache.
---
[
https://issues.apache.org/jira/browse/OPENJPA-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Hongell updated OPENJPA-209:
---
Attachment: 1_1CacheBugWineryTest.zip
run main method of BugSmallWineryTest in attached appl
Implemented with r526316.
-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
entiti
Query returning 2 entities w/1-1 relationship returns wrong types in the result
list
Key: OPENJPA-210
URL: https://issues.apache.org/jira/browse/OPENJPA-210
Project:
[
https://issues.apache.org/jira/browse/OPENJPA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Hongell updated OPENJPA-210:
---
Attachment: 1_1WrongReturnTypesBugWineryTest.zip
run main method of BugSmallWineryTest in at
[
https://issues.apache.org/jira/browse/OPENJPA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Prud'hommeaux resolved OPENJPA-208.
Resolution: Fixed
Fix Version/s: 0.9.7
Went ahead and restored the previous
[
https://issues.apache.org/jira/browse/OPENJPA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487361
]
George Hongell commented on OPENJPA-201:
In this case, the named table is the primary table for the entity a
[
https://issues.apache.org/jira/browse/OPENJPA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487362
]
George Hongell commented on OPENJPA-210:
The same test on a similar application fails with
java.lang.Instan
[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Linskey resolved OPENJPA-182.
-
Resolution: Fixed
Assignee: (was: David Wisneski)
I think that, aside from doc
[
https://issues.apache.org/jira/browse/OPENJPA-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487365
]
Patrick Linskey commented on OPENJPA-184:
-
Is this issue still open?
> use DB2 Diagnostic interface to repo
So I was thinking that a similar concept would be useful for tracking
things that need more documentation or release notes. I poked around
JIRA a bit, and discovered that it's possible to create custom fields.
Derby has a multi-checkbox custom field that includes the following:
_ Patch Available
_
+1
On Apr 6, 2007, at 5:13 PM, Patrick Linskey wrote:
So I was thinking that a similar concept would be useful for tracking
things that need more documentation or release notes. I poked around
JIRA a bit, and discovered that it's possible to create custom fields.
Derby has a multi-checkbox cus
60 matches
Mail list logo
