Interesting. I bet that the problem is that you directly set the public
field in your test code, but you didn't run the OpenJPA bytecode
processor over the test code, so OpenJPA didn't intercept the field set.
If you want this type of use case, OpenJPA needs to know about (and
process) the
If you have a null indicator for the collection / map field, then
OpenJPA will preserve the null-ness.
Otherwise, the default value will be dictated by what your no-args
constructor does (or, equivalently, what your member field
initializations do).
-Patrick
--
Patrick Linskey
BEA Systems,
On Dec 11, 2006, at 2:09 PM, Patrick Linskey wrote:
If you have a null indicator for the collection / map field, then
OpenJPA will preserve the null-ness.
What's that? I see you can specify a column as being not nullable
but I don't see anything in the spec about null and collections.
There's certainly nothing wrong with that approach.
However, the situation is not as simple as it seems. When
used in a
JTA
environment, by default an EntityManager will use a transactional
persistence context. This means that each transaction essentially
automatically gets a new
-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: Monday, December 11, 2006 2:23 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Collection (or Map) relationships and null
On Dec 11, 2006, at 2:09 PM, Patrick Linskey wrote:
If you have a null
Hi,
I noticed that the latest docs on our website is 0.9.0. Do we have a
process in place for updating them at this point? Also, I noticed that I
could navigate to docs either from the main site
(http://incubator.apache.org/projects/openjpa or
http://incubator.apache.org/openjpa), or via the
1. Loaded instances last stored with a null or empty collection/map
are restored with an empty collection/map, period. You can ignore
all the talk about null indicators.
2. Instances you construct yourself will maintain their null vs.
empty field values at least until persist. Beyond that
The spec defines that the way to get
application-managed EMs is via a call to
Persistence.createEntityManager(). Container-managed EMs come from
PersistenceProvider.createContainerEntityManager() (or
something like
that).
App managed em suck because you can't use JTA transactions.
Oops ... I forgot to do that when I released. I've uploaded them and
added the link to:
http://cwiki.apache.org/openjpa/documentation.html
It takes a little while for the static update to propagate to the
server.
Once the synchronization happens, I'll update the building page of
the
Hi Patrick,
Thanks for your detailed reply.
Patrick Linskey wrote:
If what you're looking for is to hold the cursor to the DB open across
multiple requests, you'll need to create an extended-persistence-context
EM (either via a stateful session bean or via using a non-JTA entity
manager,
This is a major hole in the JPA spec if you ask me.
Once upon a time, there was a spec called JDO. It had a API
javax.jdo.JDOHelper.getObjectId(Object pc);
I think it got left out while copying ;)
Pinaki Poddar
BEA Systems
415.402.7317
Dain-
Note that you could always introspect on the class and look for the
@Id annotation, and get the value of the Field/Method on which the
annotation resides. This is pretty heavy-handed, and doesn't work for
XML mappings, but it is one possible way to do this without making
Hi Dain,
I've never seen an @Entity without an @Id annotation. I don't believe
it is a valid JPA mapping without an @Id. That said, it's not
required to be named Id.
So are you writing a framework or sample code? For a framework, it
would be nice to be portable. For sample code, who
Hi,
Note that not all databases support efficient FirstResult and
MaxResults implementations. But even those that don't have built-in
support for skipping n rows, the usual use case is to skip where n
is small. The most frequent case is FirstResult == 0 followed in
rapidly descending
On Dec 11, 2006, at 6:03 PM, Craig L Russell wrote:
Hi Dain,
I've never seen an @Entity without an @Id annotation. I don't
believe it is a valid JPA mapping without an @Id. That said, it's
not required to be named Id.
I'm not using annotations at all. Everything is done in the mappings
FWIW, OpenJPA uses SQL syntax (rather than JDBC) for ranges for all
databases but JDataStore, to my knowledge.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may
On Dec 11, 2006, at 6:03 PM, Craig L Russell wrote:
Hi Dain,
I've never seen an @Entity without an @Id annotation. I don't
believe it is a valid JPA mapping without an @Id. That said, it's
not required to be named Id.
I'm not using annotations at all. Everything is done in the
Dain Sundstrom wrote:
This is a major hole in the JPA spec if you ask me.
+1 !
I don't use @Id either
--
View this message in context:
http://www.nabble.com/Get-primary-key-from-persistent-bean-tf2796004.html#a7827429
Sent from the open-jpa-dev mailing list archive at Nabble.com.
You new it was coming... so do Map based collections work? :)
As many of you know, I'm trying to implement CMP2 on top of OpenJPA.
To implement CMR collection sets, it would be very convenient to have
a MapPK, Bean instead of just a SetBean, so I was very pleased to
see support for this
19 matches
Mail list logo