As long as you are inside a transaction, the fields are fetched as you access
them -- irrespective of whether they are in the fetch plan or not. Let us
take a concrete example.
Consider an entity X with three fields id and a,b.c (whether they are
single- or multi-valued is not relevant in this con
I made an issue and attached some patches:
https://issues.apache.org/jira/browse/OPENJPA-1741
On Wed, Jul 21, 2010 at 9:44 AM, David Minor wrote:
> Would it also make sense for getPathOrConstant() to call
> isSeenVariable() prior to attempting the class lookup? That seems to
> work for a query li
first thank for your response,
not only openJPA is fun me, but the forum is friendly.
>>Donot understand the question properly.
me too, and my english is poor ;)
i will try a simple one.
say that inside a transaction, i select a Customer with a fetchplan which
only return the Customer name.
if a
first thanks for your response
2. No idea, I simply forbid lazy, why would you leave a lazy attribute ? It
will cause an extra request that has a cost ...
it mean that you are always fetchplan and never graph navigation.
i want leave lazy beahvior because i'am not the owner off the mapping cod
Specifically, the SLF4JLogFactory in OPENJPA-1732. I'm looking at
pulling the commons-logging fix in OPENJPA-1735 in now
-Donald
On 7/21/10 1:19 PM, Donald Woods wrote:
> Would be easy to backport, but since 2.0.x is in maintenance mode, I
> don't see us integrating these features anytime s
I'd like to start cutting a 2.0.1 release on August 2nd.
Are there any critical issues that we should try and look at before then
that are not already assigned to 2.0.1 and don't have an owner?
-Donald
Would be easy to backport, but since 2.0.x is in maintenance mode, I
don't see us integrating these features anytime soon
-Donald
On 7/20/10 10:10 PM, Craig L Russell wrote:
> Hooray.
>
> Are the patches such that they could be applied to the 2.whatever.x
> branches? If anyone volunteers fo
As you are aware, OpenJPA L2 caches communicate to their counterparts running
in other remote processes via RemoteCommitProvider. Out-of-box providers
communicate via TCP sockets (do not remmeber whether JMS protocol is
provided out of the box, but one did exist for OpenJPA's earlier
incarnations)
Would it also make sense for getPathOrConstant() to call
isSeenVariable() prior to attempting the class lookup? That seems to
work for a query like:
"select do from DomainObject do where do.uid > 10 and do.length < 4"
but wouldn't work as well for a query like
"select do.anotherObject from Domai
3. Yes, it is possible to activate fetchplan dynamically, for only one request
if you want.
2. No idea, I simply forbid lazy, why would you leave a lazy attribute ? It
will cause an extra request that has a cost ...
1. I'm not sure in your exact context because we annotate at attribute level
rat
> 1)Is it possible that fetchplan leave field in lazy mode and not return
null value to the fields unselected ?
Donot understand the question properly. But if the question is how the
serialized state of an entity will be (when, say, the entity is accesses and
then detached and serialized to web
The reported observation that OpenJPA is 50% slower than Hibernate does not
ring true to me based on
some comparative performance runs for CRUD operations on personal laptops.
The results for OpenJPA looks comparable to EclipseLink and better than
Hibernate. The basic catch is OpenJPA by default
I can assure you, there is no panic on this side. My general perception is
that the OpenJPA performance is quite good or at least nowhere near being the
bottleneck of my system.
That stated, benchmarking performance is one of those tasks that deserves some
attention periodically. I'll welcom
Hi,
we have three little questions about fetchplans(we love it)
How can we configure our fetching to get element of a Map ?
addField(CustomerImpl.class, );
Map belong to Customer with this mapping
@OneToMany(targetEntity = CustomerProfileValueImpl.class,
casca
As always, I'd take a micro benchmark such as this one with a grain of salt.
This isn't an apples to applies comparison. Also, this article is comparing
half tuned JPA implementations.
Hopefully in the coming days I'll get some time to play around with the code
that is posted to this article.
-Ri
FYI:
http://java.dzone.com/articles/jpa-performance-optimization
kind regards,
Christiaan
--
View this message in context:
http://openjpa.208410.n2.nabble.com/Performance-comparison-tp5321131p5321131.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Thanks for the link. Very interesting article.
I realize that the focus of OpenJPA 2.0 has been on implementing the JPA 2.0
specification but, assuming this article is valid, the current performance is
roughly half that of Hibernate. Perhaps someone closer to the codebase can
offer an assess
17 matches
Mail list logo
