Hi Guys,
I'm the guy that put the original ActiveMQ design together. If you want
I'll tweak it some more for you guys. Perhaps change the color scheme? Or
do you just want a better integrated banner/logo? Once we get that done,
perhaps you want a cool little software box like the ones that I
Please disregard. Craig's helping me to get through.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
I see several possible problems with this commit. Are there tests
for this functionality checked in?
1. The property and logic for using the DefaultSchemaName are defined
in MappingInfo, but the default schema name is only ever set into
ClassMappingInfos. Not FieldMappingInfos,
Hiram-
I'm the guy that put the original ActiveMQ design together. If you
want
I'll tweak it some more for you guys. Perhaps change the color
scheme? Or
do you just want a better integrated banner/logo?
Personally, I think it would be fantastic if we had someone with
clear design
Hi Abe,
The testing I've done was to take a rather simple entity hierarchy and use
the mapping tool to generate sql. Most of the verification was manual
inspection of the sql file. I didn't decide on the best way to test it in a
unit test - I suppose generating the file and grepping for the
Here is the stack trace:
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'entityManagerFactory' defined in class path resource
[spring/AbstractTransactionalCommonSpringBase.xml]: Invocation of init
method failed; nested exception is
kodo.conf.KodoProductDerivation.beforeConfigurationLoad(KodoProductDeriv
ation.java:93)
Is Kodo available in your runtime environment or only OpenJPA?
The stack trace suggests that you have a Kodo installation.
Please elaborate the runtime environment with versions of OpenJPA, Kodo,
Spring you
This is strange. Autoboxing turned off somehow? I must be doing
something wrong. Just checked out from the tip of trunk,
[INFO] Building OpenJPA JDBC
[INFO]task-segment: [install]
[INFO]
[INFO]
This is strange. Autoboxing turned off somehow? I must be doing
something wrong.
...
/Users/clr/openjpa/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java:[242,31] incompatible types
Stuff if kernel needs to be 1.4-compatible.
Notice: This email
Hi David,
The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.
Can you please fix this?
Craig
public String getForUpdateClause(JDBCFetchConfiguration fetch,
boolean forUpdate) {
String isolationLevel = null;
Boolean updateClause = null;
I'm a little nervous about this change still. I don't like it that we're
adding yet another way to configure locking, especially since it seems
like the lock level settings should be sufficient (or nearly so) to
handle per-transaction / per-query lock levels.
I also still do not believe that
The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.
Can you please fix this?
And I'd like to see all those hints defined as static constants on
the dictionary class and named for DB2 (if they're that specific) and
capitalized while you're at it -- see
i can also pass along a maven2 project
Can you post the Java source of the test case and domain classes for us
to reproduce the error?
afaik, Application identity classes like PageId are not enhanced in
current versions, they used to be.
Pinaki Poddar
BEA Systems
415.402.7317
yes will do that
ritika
On 4/3/07, Craig L Russell [EMAIL PROTECTED] wrote:
Hi David,
The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.
Can you please fix this?
Craig
public String getForUpdateClause(JDBCFetchConfiguration fetch,
boolean forUpdate) {
String
Never mind. I fixed it. I guess we still need to decide whether the
change goes in, but meantime it should compile...
Craig
On Apr 3, 2007, at 12:58 PM, Ritika Maheshwari wrote:
yes will do that
ritika
On 4/3/07, Craig L Russell [EMAIL PROTECTED] wrote:
Hi David,
The DB2Dictionary
Yes, we use Kodo 4.1.2. The bundled openJPA version is 0.9.5, but we met
some problem so we downloaded 0.9.6 and it worked fine with Kodo 4.1.2 and
Spring 2.0.2. Now we need to use LinkedHashSet instead of HashSet in our
JPA entity collection fields and 0.9.6 does not support it. It seems that
SQL provides capabilities for tuning of locking. In the case of DB2
this involves setting the isolation level, update lock, result set
optimize set, etc.
JPA spec does not provide support for these concepts but does provide a rather
open ended setHint api. It is our intent to make use this api
open ended setHint api. It is our intent to make use this api so that
users can
sets these values without having to make use of OpenJPA specific apis
-- granted the hint name and value would be OpenJPA specific.
... for certain values of our. I think that it's important that we
discuss API
Pinaki Poddar [EMAIL PROTECTED] wrote: i can also pass along a maven2
project
Can you post the Java source of the test case and domain classes for us
to reproduce the error?
i sent a .zip of the maven2 project to you directly. if there is a better place
to post it, let me know.
afaik,
Thanks Patrick,
That's exactly what I needed. I'll add a testcase shortly.
I read through your response to one of Dave's commits and I think it applies
to mine as well. Rather than hijacking that thread, I'm re-posting the
relevant part here along with my response :
I don't think that we
My experience is that customers don't like and tend not to use
proprietary apis. They tend to understand and use the standard apis.
If we can make a standard api do what we need that should be the
preferrred approach over creating proprietary apis and annotations and
then having to educate folks
On the other hand, I think there are cases where we can
include limited
functionality in the current release and then complete the function in
release+1. An example of this is what I intended to do in
OpenJPA-179.
I agree completely. In the case of OPENJPA-179, while I acknowledge that
+1
Always looking for some creative talent to make web presence better.
Craig
On Apr 3, 2007, at 6:22 AM, Hiram Chirino wrote:
Hi Guys,
I'm the guy that put the original ActiveMQ design together. If you
want
I'll tweak it some more for you guys. Perhaps change the color
scheme? Or
I agree that it would definitely make it easier to get started with
the project's binary. The only downside is if a user might want to
replace any of those JARs with newer -- presumably compatible! --
versions for some reason. It may not be an issue with OpenJPA, but
with things like Struts,
I was confused in result of my test cases.
My test is about JPA exceptions. I use derby in my tests.
The first case is simply persist an object, the PK of the object has existed
in database,
so exception arose.
entityManager = factory.createEntityManager();
Cool -- that explains it then.
EM.commit() must throw RollbackExceptions (and
org.apache.openjpa.persistence.RollbackException extends
javax.persistence.RollbackException) when the transaction is rolled back
during the course of the commit.
If you get the nested exception from the
I can't find EntityExistsException nested in RollbackExceptions.
http://www.nabble.com/file/7646/exception.jpg
Will exception mechanism be planned to improve?
I think it's very important.
Patrick Linskey wrote:
Cool -- that explains it then.
EM.commit() must throw RollbackExceptions
Can anyone explain why this rule is in effect:
When using property access, only the getter and setter method for a property
should ever access the underlying persistent field directly. Other methods,
including internal business methods in the persistent class, should go through
the getter and
Anyone seen this before
WARN [main] openjpa.MetaData - Found duplicate query StoreFXPK in class
.. Ignoring.
This class has only three such named queries all different names and different
actual queries. See following
@NamedQueries( {
@NamedQuery(name = StoreFXPK, query =
The main reason to support getter / setter access is for implementations
that cannot intercept field accesses. So, the getters and setters are
there so that the JPA implementation can create a subclass of your
entity type (hence the no-final-classes rule) and track what happens as
you invoke the
Granted, but with a reasonable implementation the cost should be
low for:
at commit / flush time compare the current values with the original values
to figure out what to write back to the database.
If you are going to issue tuned updates to the DB, determining
what really changed (as opposed
If you are going to issue tuned updates to the DB, determining
what really changed (as opposed to what setter methods were
called) can avoid unnecessary DB overheads.
... tuned for your implementation, that is. Often, business needs
require that a transaction involves a large number of
32 matches
Mail list logo
