On 4/19/07, Phill Moran [EMAIL PROTECTED] wrote:
Here it is:
[2007-04-18 18:37:07,937] INFO ca.BidSpec.testing.emall.UserFactoryTest Began
transaction (1): transaction manager
[EMAIL PROTECTED]; default rollback =
true
25547 WARN [main] openjpa.MetaData - Found duplicate query
I don't know how feasible it is, but maybe if openjpa can
detect that the column used to store a char is defined as SQL
CHAR(1) then the mapping to the database character is used.
And we can then depend on the database to signal that it's
unhappy with storing a char that doesn't fit.
On 4/19/07, roger.keays [EMAIL PROTECTED] wrote:
I have a list which is marked @ElementDependent and also CascadeType.ALL.
Adding and removing items from the list works fine, and those elements are
deleted from the database. When I try to delete the owning entity though, I
get the exception
I am using MySQL version 5
The stack trace only shows because have wrapped this in a try/catch. The
exception becomes NPE due to OpenJPA trying to make a Person object form more
than just Person Object data, it fails to do this (silently) and the object it
was to be assigned to become an NP
I
columnDefinition on @Column doesn't work
Key: OPENJPA-224
URL: https://issues.apache.org/jira/browse/OPENJPA-224
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 0.9.6
On 4/19/07, Phill Moran [EMAIL PROTECTED] wrote:
I am using MySQL version 5
The stack trace only shows because have wrapped this in a try/catch. The
exception becomes NPE due to OpenJPA trying to make a Person object form more
than just Person Object data, it fails to do this (silently) and
Thanks Jacek,
Store is annotated with @Entity:
@Entity
@Table(name = manufacturer, schema = bidspec)
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@NamedQueries( {
@NamedQuery(name = StoreFXPK, query = SELECT s FROM Store s
WHERE s.id = :primaryKey),
Another alternative is to back out the changes for OPENJPA-182 until we get
the complete solution.. But, looking at the changes for OPENJPA-182, that
looks to be quite the job and I'm not sure how many of these parts have been
touched since that commit... I would rather wait until OPENJPA-222
On 4/19/07, Phill Moran [EMAIL PROTECTED] wrote:
Thanks Jacek,
Store is annotated with @Entity:
That might imply an incorrect behaviour of OpenJPA. I doubt if I can
help more than just a spec guidance ;-) I'll have to set up the
environment to reproduce the issue as OpenJPA doesn't seem to
Will do and thanks again
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski
Sent: April 19, 2007 10:57 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Named query created in error
On 4/19/07, Phill Moran [EMAIL PROTECTED] wrote:
[
https://issues.apache.org/jira/browse/OPENJPA-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490094
]
Jacek Laskowski commented on OPENJPA-224:
-
What database do you use? I ran a test case with an entity
Hi Kevin,
I agree that the problem with sub-selects on DB2 seems significant
enough to stop the release.
Craig
On Apr 19, 2007, at 7:52 AM, Kevin Sutter wrote:
Another alternative is to back out the changes for OPENJPA-182
until we get
the complete solution.. But, looking at the changes
Hi Kevin,
We should try to do a better job of getting test cases checked in for
significant patches. Can the tests that you're using to validate the
222 changes be made available to the rest of the community?
Perhaps we should expand on the integration test concept used now for
examples
Hi Jacek,
On Apr 19, 2007, at 7:56 AM, Jacek Laskowski wrote:
I thought I needed to add the class names to persistence.xml to
have them
post-processed.
What do you mean by post-processed. There's no notion of
post-processing in JPA.
Post processing is a common term used to describe
Jacek,
thank you for diving into this. I added the following node to my
persistence.xml right
after the classes - List:
exclude-unlisted-classes true/exclude-unlisted-classes
It seems that the duplicate query warning stays - did I add it the
wrong way?
hans
Am Mittwoch, den 18.04.2007, 00:16
Craig,
Valid request. But, in this case, we are actually hitting a few snags with
the OpenJPA unit test bucket! Just configuring a new profile to run with
DB2 9.1 caused some heartburn. I'm not sure the current status (I've been
involved in some other efforts). So, in general, I agree, we
Hello Hans,
I don't know if having a value of true should have made a difference,
but most examples I have seen are simply:
exclude-unlisted-classes/
You could try that and see if it makes a difference (hopefully it will)
Jay
Hans J. Prueller wrote:
Jacek,
thank you for diving
Am Donnerstag, den 19.04.2007, 12:14 -0500 schrieb Jay D. McHugh:
You could try that and see if it makes a difference (hopefully it
will)
Unfortunately NOT.
Can anybody else with that duplicate-query problem try it?
Hans
signature.asc
Description: Dies ist ein digital signierter
Hello all,
I am trying to map a one to many relationship with the 'one' side as the
relationship owner using @EntityJoinColumn.
Actually, I am trying to do this several times within my persistence unit.
In two cases, it seems to be working - but no matter what I do
(including giving up on
Jay-
Nothing jumps out at me as being wrong with your mapping...
Note: I don't get any errors or exceptions, just no secondary
queries when I do a 'find('
If you call ComponentClass.getAttributes(), are you saying that no
SQL is executed? That would be surprising. Can you enable SQL
Sorry, I meant to send this out sooner but I'm rescinding this vote. The
docbook jar needs to be removed and we need to resolve the problem with DB2.
On 4/19/07, Craig L Russell [EMAIL PROTECTED] wrote:
Hi Kevin,
I agree that the problem with sub-selects on DB2 seems significant
enough to
Marc,
Here is the code block:
System.out.println(About to do a 'getAttributes' call...);
componentClass.getAttributes();
System.out.println(Finished the 'getAttributes' call...);
And here is the trace:
40217 palmJPA TRACE [http-0.0.0.0-8080-4]
Jay-
Nothing happened at all in between the two System.out.println's -
is there a more verbose level of logging than TRACE?
No, that is showing all the SQL that OpenJPA is executing.
The fact that ClassAttrib.classID is referenced as the join column,
but it is an unmapped attribute in
On 4/19/07, Jacek Laskowski [EMAIL PROTECTED] wrote:
I assume you're working with Java SE environment, aren't you? I'm
asking as the exclude-unlisted-classes is only intended for javase env
not javaee.
Wrong, wrong, wrong! Sorry for messing simple things up. I meant that
Jacek,
don't bother that you messed something up. At least from the XML-Schema
definition I was able to derive the right
things I think:
Am Donnerstag, den 19.04.2007, 20:36 +0200 schrieb Jacek Laskowski:
Not applicable to Java SE
persistence units.
So in that case this won't change
On 4/19/07, Hans J. Prueller [EMAIL PROTECTED] wrote:
So in that case this won't change anything for us - Not applicable to Java
SE PUs. We ARE using OpenJPA in a Java SE
persistence unit (at least from the view of JPA our J2EE1.4 container will
be only SE).
So did I understand you wrong? I
Interesting on the JTA stuff a lot of overhead if you are not planning dist
trans?
As an aside what is the Spring env considered?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski
Sent: April 19, 2007 3:35 PM
To:
The result with your suggested change to the buildSchema properties is exactly
the same as before. FWIW, I'm using PostgreSQL 8.2.
--
Well,
Removing the 'classID' field from the ClassAttrib class did not get the
persistence to work.
I added the classID back to the ClassAttrib class and this time
annotated it (the annotation somehow got lost along the way of all my
tries).
The link did not work.
So, I tried your
Jay-
Something is fishy. I can't understand why it wouldn't work.
Are you able to persist individual ClassAttrib instances (regardless
of the owning ComponentClass)?
Also, if you try adding a fresh new one-to-many relationship to some
new class, is that ignored as well?
On Apr 19,
Looks like the fail got moved outside of the if(dict instanceof
DB2Dictionary) check.
I'll put in a fix.
On 4/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: wisneskid
Date: Thu Apr 19 14:58:46 2007
New Revision: 530563
URL: http://svn.apache.org/viewvc?view=revrev=530563
Log:
Hi, all. I am hoping you can help me out here. You don't have a users
list so I'm sending it to dev.
I've been implementing some code against JPA and I was trying to figure
out how to handle a transaction rollback. I wasn't sure if JPA is
responsible for rolling back the state of any
In generic JPA, the only way to deal with the situation you
describe would be to manually call EntityManager.refresh() on
each instance that was involved in the transaction so as to
ensure that it is up to date.
Actually, I think it's even tougher than this. I think that after
rollback,
I thought that under any circumstance (except primary key messed up) that a
refresh would reload current database object image? If this is not the case how
does refresh work under any circumstances? Does it validate that the detached
object is in a valid state as a gate to refresh?
-Original
That's what I thought: broken and detached. Might as well just throw
them out. Not to be blunt, but this just sucks. It's as if JPA
believes nobody will ever really experience a rollback...
Bleagh!
David
Patrick Linskey wrote:
In generic JPA, the only way to deal with the situation you
Yeah, it's not ideal, and is something we're hoping to resolve in the
next version of the spec. The good news is that OpenJPA provides a bunch
more flexibility.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This
Dave beat me to it, but I was able to verify that the unit tests pass on
Derby and DB2. Has anyone tried running on Oracle? I know it shouldn't
matter for this fix but it can't hurt.
On 4/19/07, Michael Dick [EMAIL PROTECTED] wrote:
Looks like the fail got moved outside of the if(dict
37 matches
Mail list logo
