Sorry,
Here the source code.
Please help me.
Teste.java
import java.util.Iterator;
import java.util.List;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.
Hi Craig,
On 10/4/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
>
> Hi Kevin,
>
> On Oct 4, 2007, at 1:00 PM, Kevin Sutter wrote:
>
> > Hi,
> > It seems that the IBM JDK is cloning a Calendar object when
> > performing the
> > .equals() method.
>
> Why is that?
:-) Who knows? I'm not privy to
Pinaki,
No caching is turned on. The only cache that I am aware of that is turned
on by default is the Query Compilation Cache. All other caches need to be
explicitly configured. I have not configured for any caches. I am running
with the standard "test" persistence unit definition in our persi
Is L2 cache configured for this experiment? If datacache is active, then
that the state may be delivered from there itself without hitting the
database.
Does the test behave differently, if you set
a) datacahe off
or b) evict from both L1 and L2 cache before refresh?
To ensure that em.evi
Hi Kevin,
On Oct 4, 2007, at 1:00 PM, Kevin Sutter wrote:
Hi,
It seems that the IBM JDK is cloning a Calendar object when
performing the
.equals() method.
Why is that?
If I call .equals() on one of our Calendar proxy objects,
the underlying implementation seems to be cloning the object b
Hi,
>From reading the spec and the Pro EJB 3 book, I was under the impression
that a call to em.refresh() would refresh from the database regardless. No
questions asked. But, I am finding that we don't work that way. I made a
simple update to our simple PersistenceTest using the AllFieldTypes
(n
One of the reasons of these objects being proxied is that their change
can mark the owning persistent entity as dirty.
Pinaki Poddar
972.834.2865
>-Original Message-
>From: Evan Ireland [mailto:[EMAIL PROTECTED]
>Sent: Thursday, October 04, 2007 3:29 PM
>To: dev@openjpa.apache.org
>S
Just curious, why are Calendar objects being proxied in the
first place?
> -Original Message-
> From: Kevin Sutter [mailto:[EMAIL PROTECTED]
> Sent: Friday, 5 October 2007 9:01 a.m.
> To: dev@openjpa.apache.org
> Subject: Cloning Calendar proxies
>
> Hi,
> It seems that the IBM JDK is c
Hi,
It seems that the IBM JDK is cloning a Calendar object when performing the
.equals() method. If I call .equals() on one of our Calendar proxy objects,
the underlying implementation seems to be cloning the object before
determining the equality. While using this cloned object, one of the sette
Thanks for all the help, everything is going smoothly now. Like I said, the
latest snapshot took care of the OneToOne relationship and it makes sense
that enums are just basic.
Thanks again!
Reece
Kevin Sutter wrote:
>
> On 10/4/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
>>
>>
>> I believe
Craig-
Unfortunately, it seems that all of the pages that embed dynamic
content (like RSS feeds) need to be "touched" to force an update to
the content.
The cumbersome process is as follows:
1. Go to http://cwiki.apache.org/confluence/display/openjpa/Mailing%
20Lists
2. Log in and edit th
I notice that the mailing lists page of our site http://
openjpa.apache.org/mailing-lists.html was last updated in August. Is
the update supposed to be manual or automagic?
Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PR
On 10/4/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
>
>
> I believe that you can leave out the @Basic annotation for enums if
> you'd prefer, as well.
That is correct. @Basic is optional for enums.
Kevin
-Patrick
>
> On 10/4/07, rgarret <[EMAIL PROTECTED]> wrote:
> >
> > Alex,
> >
> > I am
This is a bug; see OPENJPA-392.
I just checked in a fix (but no test cases); it should be in the next
1.1.0 snapshot.
-Patrick
On 10/4/07, AlexD. <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Patrick Linskey-2 wrote:
> >
> > If you remove the columnDefinition, does the problem go away? I'm not
> > sugg
[
https://issues.apache.org/jira/browse/OPENJPA-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Linskey updated OPENJPA-392:
Fix Version/s: (was: 1.0.1)
> Some columnDefinition annotation properties incorrectly
Some columnDefinition annotation properties incorrectly used as column name
instead of type
---
Key: OPENJPA-392
URL: https://issues.apache.org/jira/browse/OPENJPA-392
[
https://issues.apache.org/jira/browse/OPENJPA-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532439
]
Patrick Linskey commented on OPENJPA-347:
-
> OpenJPA loads the foreign key fields eagerly regardless of the
Hi,
enum field types should be mapped as @Basic; @ManyToOne is for a
back-pointer on a one-to-many relationship (i.e., a collection of
entities). So, it should only be used for persistent types, not simple
types like enums.
I believe that you can leave out the @Basic annotation for enums if
you'd
Hi,
Patrick Linskey-2 wrote:
>
> If you remove the columnDefinition, does the problem go away? I'm not
> suggesting that as a solution, but the answer will help debug the
> problem.
>
Yes, the problem goes away if I delete the columnDefinition.
best regards,
alex
--
View this message in cont
Alex,
I am enhancing all of my model classes at build time. I found a fixed bug
that pertains to my issue: http://issues.apache.org/jira/browse/OPENJPA-347.
After upgrading to the latest snapshot my OneToOne relationship behaved
properly but the ManyToOne still eagerly fetched. I changed from Man
Hi,
> As you see the columnDefinition is taken instead of column name (the SQL
> will be correct if I delete columnDefinition for this column).
>
> Has somebody some ideas how to fix SQL without removing of columnDefinition?
If you remove the columnDefinition, does the problem go away? I'm not
su
21 matches
Mail list logo
