[
https://issues.apache.org/jira/browse/OPENJPA-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474480
]
Abe White commented on OPENJPA-146:
---
Cancel my previous comment. Embedded PCs are handled very differently than
[
https://issues.apache.org/jira/browse/OPENJPA-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474474
]
Abe White commented on OPENJPA-146:
---
Looks like a good fix to me. Do you need someone to commit this for you
This change is causing problems in an application server
environment. I
pulled in this change this morning, re-built, and tried our perf
benchmark
(SunOne with OpenJPA) and I get the following exception:
Sorry about that. I'll revert it ASAP. I have a vague notion of
what might be cau
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473416
]
Abe White commented on OPENJPA-141:
---
> The two-way check in FetchConfigurationImpl was overlooked. Thank you.
I've looked at the code and it looks correct to me and tried various
things like making the inverse LAZY.But it always generating the
extraneous join. I've attached the entity source code.
The relationship causing problem is
@ManyToOne
@JoinColumn(name="ACCOUNT_ACCOUNTID")
private
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473234
]
Abe White commented on OPENJPA-141:
---
Craig, good catch. I didn't even look at the actual assignable method
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473172
]
Abe White commented on OPENJPA-141:
---
1. Why not keep a single assignable types map in ImplHelper?
2. I thought we
[
https://issues.apache.org/jira/browse/OPENJPA-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473122
]
Abe White commented on OPENJPA-146:
---
We don't enhance the oid class anymore, so this bug is probably fixed
First, I want to point out that I was wrong about needing to set a
lock level in code during an optimistic transaction. So actually for
us to run the benchmark, the only necessary setting is:
openjpa.LockManager: pessimistic
Contrary to what Patrick said and I backed up, we don't need to set
Secondly, are we parsing the XML file multiple times? The only
way for the first warning to be fired is if OpenJPA has read my
entity mappings, but the exception that is thrown later is a SAX
exception which implies that OpenJPA is reading the file again.
Sounds like an inefficient startup algo
We'd also have to set the LockManager property to pessimistic to get
database locks. And just to build on what Patrick is saying: OpenJPA
can do locking within optimistic transactions on individual
instances, but you have to set a lock level on the FetchPlan in code,
which I don't think we
I doubt anyone has done much performance analysis of stock OpenJPA,
especially without caching. BEA's performance efforts obviously
focus on Kodo instead. Which is why we all appreciate the
performance work you're doing now, even if we (well, mostly just me)
might harp on the details.
__
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472758
]
Abe White commented on OPENJPA-141:
---
Craig:
There doesn't appear to be any hashCode/equals performance i
does openJPA provide the strategy to re-generate another value for
the PK
or do we have to manually deal with this case?
http://incubator.apache.org/openjpa/docs/latest/manual/
manual.html#ref_guide_sequence
___
Notice: Th
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472506
]
Abe White commented on OPENJPA-141:
---
> Craig thinks: Weak references are supposed to be cleaned up if
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472455
]
Abe White commented on OPENJPA-141:
---
1. Each BrokerFactory has a ManagedRuntime. You can have multiple
Thanks for the feedback. I know that we have been running with
both the IBM
and Sun JDK's, but let me get together with my performance team and
discuss
your concerns. We will try to provide more concrete data on these
updates.
Cool. Maybe I'll learn something about weak refs and the
==
--- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
openjpa/ee/JNDIManagedRuntime.java (original)
+++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
openjpa/ee/JNDIManagedRuntime.
[
https://issues.apache.org/jira/browse/OPENJPA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471744
]
Abe White commented on OPENJPA-138:
---
o Cache the TransactionManager in JNDIManagedRuntime
+1
o Cache the Class
I think if a user throws an exception in a callback outside of a
commit operation, we should simply rethrow it to the user after we
clean up our internal state. Presumably, the specific runtime
exception has meaning to the user's code, and we don't add much
value in wrapping the exception.
[
https://issues.apache.org/jira/browse/OPENJPA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470119
]
Abe White commented on OPENJPA-119:
---
I'm not saying we need to add the new detachAll method, but I
interesting. I always did it the other way - use /* */ in code,
and // for commenting out blocks :)
If you have an IDE that can prefix every line in a block with '//' to
comment it out, it will work regardless of comment style. But for
non-IDE users, /**/ is the only efficient way to comm
I upgraded to "openjpa-0.9.7-incubating-SNAPSHOT" and still get the
same
results. By the way, thanks for your help so far.
I get table and column names when I run the tool. Are you sure you
aren't looking at old output? Can someone else attempt to reproduce
this problem?
__
Sadly, not currently. OpenJPA domain model extensions are not
currently
available in XML form. See OPENJPA-87 for a related issue.
While this is true, I believe if you just don't declare any @Id
fields we'll probably default to datastore identity automatically.
_
[
https://issues.apache.org/jira/browse/OPENJPA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469562
]
Abe White commented on OPENJPA-119:
---
"But, since I don't know how JDO is using the kernel, it's ki
[
https://issues.apache.org/jira/browse/OPENJPA-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469481
]
Abe White commented on OPENJPA-122:
---
I personally would put the _broker.assertOpen() calls before the
This sounds like something that was fixed a while ago. What version
of OpenJPA are you using?
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries a
Basically, if we have dirtied the Persistence Context, then do a
flush()
followed by the detachAllInternal(). I don't think the clear()
should be
doing this flush() operation. Any disagreement?
I agree. But note that just removing the flush call won't work for a
couple of reasons: it's
Is this the way it is supposed to work?
Yes.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential
[
https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468770
]
Abe White commented on OPENJPA-117:
---
I don't see why listeners are some special case that require more isol
[
https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468734
]
Abe White commented on OPENJPA-117:
---
I don't think we should encourage use of user objects for tracking sta
Since the time that we implemented that, we added logic (the
RuntimeExceptionTranslator interface and its implementors) that takes
care of translating from internal exception types to spec-defined
exception types across the board. We certainly could move the logic
for
logging at the trace level
So the assumption is that the caller will log the appropriate
exception-related message if such an exception is caught?
We're throwing an exception. The user has to do something with it.
It is a trivial matter for him to log it if that's what he chooses to
do, but I would expect much more
OpenJPA does not log exceptions that are thrown to your code.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may
In working on the CTS, we've discovered some assumptions that cause
OpenJPA to fail. The CTS obtains records via calls to getReference(),
and then does some work with the objects.
The tests fail outright with default OpenJPA settings, as the
openjpa.DetachState property defaults to 'loaded'. Inst
You'll also want to set ConnectionRetainMode to transaction, which
will
ensure that OpenJPA has a single connection for the duration of the
transaction.
Performing a persistence operation and then setting a savepoint is
enough to ensure you keep the same connection, regardless of the
setti
Try performing a persistence operation (persisting an entity,
changing a persistent entity, deleting an entity, etc) before setting
the savepoint. It could just be a bug with empty savepoints in
optimistic transactions (which aren't too useful anyway).
__
I see. I specifically had problems with relation tables though. I had
columns generated as _attribute_OTHERTABLENAME and the first _
didn't make
it through Derby. Hence the necessary usage of @ElementJoinColumn.
Are these mandated by the spec as well?
Yes. And as I said, there are standard
I think it could be nicer and a bit easier if OpenJPA was
automatically
eliminating the first _ from attribute names to build its default
coumn
names, don't you think?
The default column names are mandated by the JPA specification. And
unless you're using OpenJPA-specific mappings, you sh
Is there a reason why @ForeignKey is not allowed for @ManyToMany?
Because the field value is a collection, not a reference. You want
to use @ElementForeignKey.
___
Notice: This email message, together with any attachments,
SVN revision 492368 no long ignores non-String values for openjpa.*
keys in the Map passed to Persistence.createEntityManagerFactory.
___
Notice: This email message, together with any attachments, may contain
information of B
EntityManagerFactory emf =
Persistence.createEntityManagerFactory
("ode-dao");
EntityManager em = emf.createEntityManager(propMap);
Once again, you should be passing your props to
createEntityManagerFactory, not createEntityManager. As I said, use
the no-arg version of cre
OK, the problem is that we're only paying attention to openjpa.*
property keys with String values when you bootstrap through
Persistence. I have no idea why, and I'll change it momentarily.
Actually I now see why, and I might not be able to fix it before I
leave work today. For anyone who
OK, the problem is that we're only paying attention to openjpa.*
property keys with String values when you bootstrap through
Persistence. I have no idea why, and I'll change it momentarily.
But for now, you can work around the problem for your DataSource
using the "javax.persistence.nonJt
I'm able to reproduce the ConnectionDriverName problem. I'll have
more info in a bit.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affi
But if I don't provide openjpa.ConnectionDriverName the call to
createEntityManager fails with an exception saying that
ConnectionDriverName
should be provided (coming from DataSourceFactory):
You need to provide it to createEntityManagerFactory. Not to
createEntityManager. You shouldn't
When execute, for each of the Map key I'm passing I'm getting:
<4|false|0.9.6-incubating-SNAPSHOT>
org.apache.openjpa.persistence.ArgumentException: Missing getter for
property "ConnectionDriverName" in type "class
org.apache.openjpa.persistence.EntityManagerImpl".
Because you shouldn't be pass
I've been fighting for some time now with my OpenJPA configuration
and just
discovered why. It seems that you *either* consider the
persistence.xml file
*or* the map passed as parameter of
Persistence.createEntityManagerFactory.
If you look at PersistenceProductDerivation.load(String rsrc,
I don't agree with this implementation. It doesn't leave any room
for customization through MappingDefaults, it ties the ClassMapping
to the XMLSchemaParser (?!), and it's totally different than our
mapping of indexes, foreign keys, and primary keys, the other
supported constraint types.
Just using refresh does not clean up the data in the database
(getting Unique
constraints violations). Just for kicks I tried
SchemaTool.DropTables=true,
it did pass the configuration phase, but it still did not cleaned the
data/schema.
None of the options I mentioned are meant to clean up t
Caused by: org.apache.openjpa.lib.util.ParseException: There was an
error
while setting up the configuration plugin option
"SynchronizeMappings". The
plugin was of type "org.apache.openjpa.jdbc.meta.MappingTool". Setter
methods for the following plugin properties were not available in
that t
[
http://issues.apache.org/jira/browse/OPENJPA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461839
]
Abe White commented on OPENJPA-94:
--
Note that the "SynchronizeMappings" property allows you to u
Unfortunately, we don't have any automatic drop-table feature, but
I agree it would be handy (you might want to make a JIRA report
with the suggestion).
Note that the "SynchronizeMappings" property allows you to use all
the arguments of the mappingtool. So you can try something like:
bui
[ http://issues.apache.org/jira/browse/OPENJPA-90?page=all ]
Abe White resolved OPENJPA-90.
--
Resolution: Fixed
Right you are. Changed to check local columns, not foreign ones.
> "ON DELETE SET NULL" is getting overridden if the foreign c
OneToMany mappings default to using a join table unless you name the
inverse field with mapped-by.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiarie
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
Other than the cost of not having a cache (which is what I want),
it is expensive to be creating a new EntityManager for each
transaction?
No.
Looking at the docs... is this what the "Remote Event Notification
Framework" is used for?
Yes, OpenJPA uses the remote event notification framew
Why not add a way to clear the cluster cache?
Any developer is free to do so.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
en
1. You must use a new EntityManager for each test.
2. If you have the DataCache enabled, you'll have to clear it. You
can do that through:
((OpenJPAEntityManagerFactory) emf).getStoreCache().evictAll();
3. There is no way to clear the cache on cluster node B from cluster
node A; you have t
I just wanted to make sure everyone sees this, because I bet many of
us don't have our config file set up correctly (I know I didn't):
Probably the offender's local svn file settings are wrong and not as
recommended at
http://www.apache.org/dev/svn-eol-style.txt
thanks
david jencks
Hopeful
[
http://issues.apache.org/jira/browse/OPENJPA-85?page=comments#action_12451353 ]
Abe White commented on OPENJPA-85:
--
Note that the common SQL92 reserved words are maintained by the base
DBDictionary, which reads from the sql-keywords.rsrc
I tried the 0.9.7 release. orm.xml looks much better. It even
resolved my issues with one-to-many relations.
It's not usable "as is", but it's a lot closer. I have to manually
tweak the results for the following items. I don't know if all of
them are possible - or even desirable to address,
I don't feel super strongly... but I tend to lean towards less is
more. If all you need for the time being is the Id concept, do
that. Throw in a quick documentation note about what exactly that
property is... and then if people need to use just the p-name part
of it, they can run with ha
1. The reverse mapping tool creates an orm.xml but not
annotations on generated Java code. Any plans on this?
2. I fed an orm.xml to Hibernate 3. It works, but if Hibernate is
clever enough to automatically translate between camelCase Java
names and underscore-punctuated database names, it'
1. The reverse mapping tool creates an orm.xml but not annotations
on generated Java code. Any plans on this?
2. I fed an orm.xml to Hibernate 3. It works, but if Hibernate is
clever enough to automatically translate between camelCase Java
names and underscore-punctuated database names, it'
+1
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally
The merge operation takes as a parameter a detached instance, not a
new instance.
TopLink Essentials might not be able to tell the difference between
a detached and a new instance. So it might work in that environment.
But the behavior you're describing is not portable.
That said, you ca
The merge operation takes as a parameter a detached instance, not a
new instance.
TopLink Essentials might not be able to tell the difference between
a detached and a new instance. So it might work in that environment.
But the behavior you're describing is not portable.
That said, you can
With today's changes from SVN, I am hitting the following error
when running
the test bucket
Darn static class registration... can you just add that type to the
list of types registered in when getting the EMF in setUp() and see
if it fixes things? I probably should have created a new cla
Geronimo seems to be running into this problem also when is
this serp binary going to be published properly? Making sure that
an artifact is publically avaiable before using it is a pretty good
idea :-)
Sorry about the serp confusion, guys. As you may have seen, the
dependency has b
The error message is from the XML parser; we don't have much control
over it. How about posting your persistence.xml?
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, In
[ http://issues.apache.org/jira/browse/OPENJPA-73?page=all ]
Abe White resolved OPENJPA-73.
--
Resolution: Fixed
Fixed by not instantiating all plugins up front in class transformer.
> PersistenceProviderImpl.createContainerEntityManagerFactory() does
I did a little playing around, in my non-exhaustive testing it
seemed to
call classForName each time you accessed a field on an Entity.
"Select p.firstName from Person p where p.id = 1" called
QueryImpl.classForName twice.
QueryImpl.classForName uses the MethodDataRepository method I
mentio
[
http://issues.apache.org/jira/browse/OPENJPA-73?page=comments#action_12446288 ]
Abe White commented on OPENJPA-73:
--
David -- if you can verify that things also work if you don't pre-enhance,
we'll commit
I investigated a bit further and found that if I change
PersistenceProviderImpl.ClassTransformerImpl to use a
JDBCConfigurationImpl instead of OpenJPAConfigurationImpl then the
problem goes away. I'm reasonably certain that there is no need to
use a JDBCConfigurationImpl here in the class
Can anybody tell me if it is possible to stream binary data from
the database
using JPA? I noticed in the spec, support for java.sql.Blob was
removed in
one of the revisions. OpenJPA, however, seems to have a few classes
related
to streaming binary data.
OpenJPA does not have any streaming
Our internal testing framework, in this case, is vanilla JUnit. Seems
like that might be a use case that we should care about, no?
IMO, you don't subject all your users to nonstandard behavior (in
this case, adding a stack to an exception's toString) to satisfy one
braindead testing harness
@Strategy allows the specification of a custom class name in string
form. However, class names inside quotes don't refactor all that
well. I
think we should add an @StrategyClass annotation that allows
specification of a strongly-typed Class instance. What say ye?
I'm not voting either way; I
AbstractPCData needs to be modified to special-case primitive arrays
to just copy the array and cache it is an opaque value, rather than
using a List where each element is a potentially separately-cached
instance. Roger, I'd encourage you to file a JIRA issue for this
problem.
p.s. In ca
What is this 'inner exception' that you speak of? The underlying
exception is set to the cause, but the cause is not being printed.
IOW, I get all the information I need when I do an e.printStackTrace()
OK, that's how it should be then. I don't want to deviate from
Java's standard Exception.
The situation I'm looking at right now, for one: I'm seeing an
optimistic lock exception, and the OpenJPA exception translation is
obscuring the full stack, so I just get the stack from the point of
translation, rather than from the point of origin.
Then the solution is to fix the exception tran
+0.5 for moving the logic in to WASManagedRuntime.main(). Go ahead
and move
it unless someone objects, there's no real need for another class.
I went ahead and did this. I also moved WASManagedRuntime's
caching logic to its endConfiguration() callback to avoid the
threading issues that se
+0.5 for moving the logic in to WASManagedRuntime.main(). Go ahead
and move
it unless someone objects, there's no real need for another class.
I went ahead and did this. I also moved WASManagedRuntime's caching
logic to its endConfiguration() callback to avoid the threading
issues that se
[ http://issues.apache.org/jira/browse/OPENJPA-68?page=all ]
Abe White resolved OPENJPA-68.
--
Resolution: Fixed
Thanks, fixed. (FTR, the correct name is
org/apache/openjpa/enhance/PersistenceCapable)
> PCClassFileTransformer.isEnhanced() fails beca
Fair enough. But, unless Kodo is replacing the JPQL parsing, I
don't see
how you can get around this problem. I suppose it's possible that
other
performance improvements could negate the performance hit
associated with
the reflective class loading. But, it would seem that if Kodo 4.1
is
Does anyone mind if I move this class from the
org.apache.openjpa.util package to the org.apache.openjpa.ee
package? It's a very EE-specific class, and in my mind is not a
general utility other parts of the system will ever use. I'd even
consider removing the class altogether and just mov
This was one of the thoughts we had as well. But, I wanted to
check base
with you guys first to see if maybe we just didn't have it tuned
correctly.
Have you pushed any performance runs with Kodo 4.1 yet?
Kodo has additional performance and caching features, so there may be
hotspots in Op
I thought we (OpenJPA) supported the mapping of Collections of
embedded
types.
OpenJPA never supported this. It was accidentally left in from the
Kodo docs.
___
Notice: This email message, together with any attachments,
+/- 0 Neutral. Do whatever.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprieta
You're definitely missing the JDBC bits of OpenJPA, or at least the
JDBCProductDerivation isn't being found. If you get the latest
version, you can invoke the
org.apache.openjpa.conf.ProductDerivations class's main method to
print details about derivation loading to System.out. You might
[ x] Separate setUp() and tearDown()
[ ] Separate setUp() and tearDown(), but setUp() invokes tearDown()
[ ] Typically no tearDown(); put cleanup logic in setUp()
[ ] Other. Please describe.
IMO, if we're diligent in writing proper tearDown methods, there's no
reason to put the tearDown logic
Kevin --
Thanks for the test case. Unfortunately, the test will always fail
for databases that don't support auto-assigning column values. The
test should probably look for DBDictionary.supportsAutoAssign and
skip itself (early on, before any attempt to create the schema for
the classes
+1
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally
If I define a cascade persist field in an EntityX and that field is
declared to be of type EntityA but at runtime contains a non-Entity
subclass of the EntityA, (e.g. NonEntityB extends EntityA), what
happens at commit?
IMO the commit should fail with an appropriate exception.
_
Documentation still mentions BatchLimit for configuring batching but
using it causes
OpenJPA doesn't batch. The Kodo docs explain how to configure
batching in Kodo (see the docs on migrating to 4.1).
___
Notice: This ema
Thanks for sending the Channel base class. The problem is actually
very simple, and is explained here:
http://edocs.bea.com/kodo/docs41/full/html/
ejb3_overview_mapping_discrim.html
See the note about discriminator columns. The bottom line is that
when you use single-table inheritance ma
My classes use the JOINED inheritance strategy. I use the default
basic mappings and a sequence generator inside the root class.
I've joined the real classes, in fact the names of my classes are
as follow (I renamed them in my previous mail for simplicity):
Channel <- CommerceChannel <- Netwo
[ http://issues.apache.org/jira/browse/OPENJPA-41?page=all ]
Abe White resolved OPENJPA-41.
--
Resolution: Fixed
> transforming classes doesn't work
> -
>
> Key: OPENJPA-41
>
[ http://issues.apache.org/jira/browse/OPENJPA-13?page=all ]
Abe White resolved OPENJPA-13.
--
Resolution: Fixed
Resolved by converting DB-generated autoassign value to expected Java type for
column, as mapped by object field.
> GenerationType.IDENT
Sorry, the file to update is HandlerFieldStrategy.java. Better yet,
update everything: it can't hurt.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidi
101 - 200 of 254 matches
Mail list logo
