OpenJPA is in the process of creating the tables when an error occurs. It
looks like a syntax error from the database over the AUTO_INCREMENT
keyword. I didn't find any hits on the sql state and error code though.
Are there any chained exceptions? A nested SQLException might have a more
helpful
I had trouble with that too, but wasn't able to get to the bottom of it. If
you enable debug logging you might be able to spot the root cause.
It's a pain for unit testing, but the best approach might be to just list
the classes in persistence.xml with class tags.
-mike
On Tue, Jul 9, 2013 at
Looks like the security classloader and the agent enhancer are defining the
same class (with the agent getting there first). Without any clue to which
classes are entities, the agent enhances everything it finds. Anecdotal
evidence suggests that it only takes one persistence unit without a list of
Just a guess, but it looks like the entity has a bigInt mapping to a column
of char(4). I can't check the code / messages right now though, but maybe
this will give you a starting point.
-mike
On Fri, Feb 1, 2013 at 11:50 AM, Laird Nelson ljnel...@gmail.com wrote:
I'm getting a metadata
You're right about not all of Kodo's features being added to OpenJPA.
Feel free to make a feature request, in JIRA. Unfortunately a lot of the
former Kodo developers are busy on other projects, and the rest of the
OpenJPA developers might not be familiar with Kodo's features.
What I'm getting at
I think Marc published that prior to one of the older releases (OpenJPA
0.9.5, or 0.9.6). Take a look at the latest doc, and see if you can find
something similar there :
http://openjpa.apache.org/builds/latest/docs/docbook/manual.html
That feature may have been deprecated or renamed (I only took
Quick answer, you can use the openjpa.jdbc.Schema property at EMF creation
time. IIRC this won't work with EMF injection though.
A kludgy way to go would be to not define a schema in p.xml or in the
entities and let it pick up the default schema from your datasource. If you
can use a resource
Just to add to Pinaki's reply.
OpenJPA can order the SQL updates appropriately, but only if the
openjpa.jdbc.UpdateManager is set to one of the constraint update managers
(constraint or batching-constraint). See this
There is at least some interest from a subset of our users. Matthew Adams
and issue: OPENJPA-1744
https://issues.apache.org/jira/browse/OPENJPA-1744to add support for
JDO last July. I closed the issue, but Matthew responded
and the issue was reopened.
There hasn't been a lot of activity on the
OpenJPA has historically had problems with JOIN FETCH syntax, but this
sounds like a new bug.
Would you be adverse to trying OpenJPA's fetch plans instead? I mentioned it
in this post : http://markmail.org/message/wrqdyc22b2gaocux, and there's
some information in the manual at:
There have been a few emails to this list about classpath issues when
enhancing on Glassfish. I don't think there's a definitive guide to getting
automatic enhancement working though, and the general consensus is to use
build time enhancement.
That said, if you can resolve the classpath problem
What version do you have in your persistence.xml file?
If the xml header indicates version 1.0 you'll get OpenJPA's old behavior
(and the error message you're seeing). If you have 2.0 in the xml header the
JoinColumn annotation should work.
-mike
On Sun, Sep 11, 2011 at 1:49 AM, koenr
this
condition.
-mike
On Tue, Sep 6, 2011 at 11:45 AM, ljnelson ljnel...@gmail.com wrote:
On Tue, Sep 6, 2011 at 12:24 PM, Michael Dick [via OpenJPA]
ml-node+6764535-652757152-155...@n2.nabble.com wrote:
Typical applications will interact with entities (PersistenceCapable
classes) through
The PCEnhancer has its roots in the Kodo (the JDO provider that OpenJPA is
based on). The answer to your question comes from the JDO spec :
Enhancement makes the following changes to persistence aware classes:
• modifies executable code that accesses fields of PersistenceCapable
classes
not known
Hi Marc,
Could you post the query you're using, and any properties from
persistence.xml? I took a quick shot at reproducing the problem, but haven't
had any luck, maybe the query / persistence properties will help me narrow
in on the problem.
-mike
On Mon, Aug 29, 2011 at 6:07 PM, Marc Logemann
You're right, this is a bug. NAME is in the default set of reserved words
that can't be used as column names. It appears to be valid for H2 though and
we should handle it appropriately. Can you file a JIRA issue, or would you
like me to do that on your behalf?
You can escape the name column as a
The issue is OPENJPA-2045https://issues.apache.org/jira/browse/OPENJPA-2045,
if the workaround doesn't work for you let us know and we'll take a look at
that aspect too.
-mike
On Thu, Sep 1, 2011 at 8:53 AM, ljnelson ljnel...@gmail.com wrote:
On Thu, Sep 1, 2011 at 9:52 AM, Michael Dick [via
Hi Sebastian,
The binary downloads of OpenJPA includes the Java EE jars we use with
OpenJPA (look in the lib directory). The spec implementations we use come
from Geronimo, but any Java EE 6.0 compliant version of the API should work
for you.
You can also find these jars in the maven central
work (as they could be even from different
datasources).
Best regards Marcel
From: Michael Dick michael.d.d...@gmail.com
To: users@openjpa.apache.org
Date: 12.08.2011 16:03
Subject:Re: Problems when using openjpa.MetaDataFactory Property
It's a thorny problem.
Have
() Method (via a custom @Qualifier annotation)
and manipulates the MetaData accordingly.
Best regards Marcel
From: Michael Dick michael.d.d...@gmail.com
To: users@openjpa.apache.org
Date: 11.08.2011 21:57
Subject:Re: Problems when using openjpa.MetaDataFactory Property
Hi
I don't think this behavior is normal, but I haven't had a chance to look
into it. If you have a testcase handy that usually makes things quicker for
us - but we should be able to produce one fairly quickly.
In another thread Rick suggested using OpenJPA's
Some of the detach behavior depends on the version in your persistence.xml
file. It's kind of a shot in the dark, but are you validating against
version 2.0, or 1.0?
-mike
On Fri, Aug 12, 2011 at 9:56 AM, Michael Pflueger
michael.pflue...@sma.dewrote:
Hi Rick,
Yes, I'm using 2.2 trunk, ~1
Going back to your original email, the documentation is misleading. While
you could use PersistenceMetaDataFactory you'd probably prefer to use
PersistenceMappingFactory. Basically, you did the right thing by extending
the PersistenceMappingFactory..
The product derivations are confusing, because
;
@OneToMany(mappedBy=group,fetch=FetchType.EAGER
,cascade=CascadeType.ALL)
CollectionPerson persons=new ArrayListPerson();
@EmbeddedId
private GroupPK id = new GroupPK();
...
Best regards Marcel
From: Michael Dick michael.d.d
on a fix.
-mike
On Thu, Aug 11, 2011 at 2:19 PM, Michael Dick michael.d.d...@gmail.comwrote:
Hi Marcel,
Thanks for sending the embeddable PK, I was missing that part.
I see everything work if I set the MappingFactory plugin to the default
value (org.apache.openjpa...) or leave the property
Statement batching is an OpenJPA optimization. By default OpenJPA will try
to use JDBC statement batching. There's a section in the user manual at :
http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_dbsetup_stmtbatch.
Depending on the application, statement batching can
IBM provides a feature pack JPA 2.0 which will install on WebSphere version
7. You can find more information the following site:
http://www-01.ibm.com/software/webservers/appserv/was/featurepacks/osgi/
HTH
-mike
On Thu, Aug 4, 2011 at 12:54 AM, f.joe falchetto@gmail.com wrote:
Hi Mike,
Hi,
I think you're running into
OPENJPA-1583https://issues.apache.org/jira/browse/OPENJPA-1583,
which is fixed in version 2.0.0 and later (but not on 1.2.x). Is moving up
to 2.x an option for you?
-mike
On Wed, Aug 3, 2011 at 5:33 AM, joe falchetto falchetto@gmail.comwrote:
Hello,
I'm
If you're explicitly locking the entities I can see where a version update
would be appropriate. If you're just merging changes in then it's not clear
why the versions would be updated.
If you could post a testcase that would probably be the most helpful.
-mike
On Wed, Aug 3, 2011 at 10:59 AM,
I think Richard's configuration is correct. The only catch, which he pointed
out, is that you do have to specify the DBDictionary to use. Maybe I missed
something though?
I'm not sure whether having to specify the DBDictionary is the result of the
automagic connection pool support, but for the
, Michael Dick michael.d.d...@gmail.com
wrote:
I think Richard's configuration is correct. The only catch, which he
pointed
out, is that you do have to specify the DBDictionary to use. Maybe I
missed
something though?
I'm not sure whether having to specify the DBDictionary
I don't have a nice solution for you (at least not yet).
I may have an explanation for the warning that you're getting. The
javaAccessorNotSet can happen if a JNDI namespace is not available. In this
case the JPA code is looking for the Transaction Synchronization Registry in
JNDI, but it's not
Thanks for letting us know.
I copied the file to the correct location, and the link should be correct
once the mirrors update.
-mike
On Thu, Jul 28, 2011 at 8:06 AM, Georgi Naplatanov go...@oles.biz wrote:
Hi all.
Release notes for OpenJPA 2.1.1 is not available at download page.
page -
Hi,
Is there an exception logged with the message? The inner message is an INFO
message, so in itself it should be benign. I'd expect the Transaction
Synchronization Registry to only be available in JEE, so I don't think there
is anything wrong with your environment.
I'm at a loss regarding the
If the tables have already been created you can use OpenJPA's reverse
mapping
toolhttp://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_pc_reverse.
It will recreate the .java files for you in addition to the XML mapping
file. There's no need to use the generated .java files
I'm not sure it's a bug. A quick read of the XSD in the spec backs up the
parse exception, the id tag can't contain a join column..
Shouldn't the xml be something like this?
attributes
id name=claimVersion
/id
many-to-one name=claimVersion
join-column
Sorry about that, I missed the email about having OpenJPA generate the XML
(which is pretty cool).
Thanks for the clarification,
-mike
On Mon, Jul 18, 2011 at 5:09 PM, Jason Pyeron jpye...@pdinc.us wrote:
-Original Message-
From: Pinaki Poddar [mailto:ppod...@apache.org]
Sent:
I don't have any general tips that will apply to every situation, so here
come more questions.
How are you loading the rows (one big query, or several smaller ones)?
Do you have a lot of relationships in your entities (the resulting joins can
slow things down).
Do you see a lot of connections
It looks like you have the log4j-over-slf4j bridge on your classpath. Or
some combination of the different logging facilities.
So commons-logging detects log4j and tries to use it. Log4j tries to
delegate to slf4j, but that fails due to the missing implementation class.
Do other parts of your
On Wed, Jul 13, 2011 at 12:00 PM, Jason Pyeron jpye...@pdinc.us wrote:
-Original Message-
From: Michael Dick [mailto:michael.d.d...@gmail.com]
Sent: Wednesday, July 13, 2011 12:53
To: users@openjpa.apache.org
Subject: Re: Logging questions
It looks like you have the log4j
Here's what I've seen (a slight addition to Fay's post in Nabble)
ElementCollection may be used with Collections, or Maps. It should not be
used with an array - like the original poster's example.
PersistentCollection is specific to OpenJPA and may be used with an array
(int[], String[]), or a
I think we can ignore the warning about Phone_ for now. The enhancer will
not automatically ignore the MetaModel classes, but it shouldn't be hurting
anything.
I haven't been able to reproduce the other warning. If your project is
available on github please post a link - that might be the
Off the top of my head I'd say that the first case will perform slightly
better. In the first case OpenJPA will get a single connection to the
database, in the second case we'll get two (one for merge, and another for
refresh). You could change this behavior with the
openjpa.ConnectionRetainMode
Thanks for the thorough description of the problem!
The problem here is that you're merging a new instance of ToBeMerged, which
has a relationship to a detached RelatedObject. The merge operation isn't
cascaded by default, so the rules become a little muddy.
Adding CascadeType.MERGE will also
Hi Harald,
I don't think the VirtualMachine class (the class we're looking for in
tools.jar) has moved. I compared 1.6.0_22 and 1.6.0_25 and it's in the same
location - JDK_HOME/lib/tools.jar.
The problem here is that java.home is pointing to the JRE location instead
of the JDK location (which
, but that didn't work.
Regards,
Harald
Original-Nachricht
Datum: Thu, 16 Jun 2011 08:50:33 -0500
Von: Michael Dick michael.d.d...@gmail.com
An: users@openjpa.apache.org
Betreff: Re: Dynamic Enhancement not working on Oracle JDK/Linux
Hi Harald,
I don't think
Rick's right on both counts. TrackChanges doesn't eliminate proxies - it
should just make them no-op.
We also need the proxies for for managed entities to track the state of non
primitives (Dates, collections etc.). I don't think we have code in place
that falls back and does a more thorough
manager much faster because it does not bother detaching the proxies, but it
still attaches proxies during commit, so commit does not run any faster.
-Aron
On 6/15/2011 10:37 AM, Michael Dick wrote:
Rick's right on both counts. TrackChanges doesn't eliminate proxies - it
should just make
I'm glad its working for you. The way I read the docs is that the warning
will come up if you do not have a LoadTimeWeaver configured (and it's safe
to ignore when it does happen).
I don't have a Spring environment handy to double check this though. If you
saw the opposite behavior I'm happy to
What's different between the working module, and the broken one?
You've checked that persistence.xml is on the classpath. Is it in
src/main/resources or src/test/resources, or some other location?
-mike
On Tue, Jun 7, 2011 at 8:08 AM, infinity2heaven
infinity2hea...@gmail.comwrote:
The issue
I took a look at the openjpa build where we also use this plugin. It looks
like the auto-detection of persistence.xml isn't working for the enhance
goal, but works for the enhance-tests goal. I'm not terribly familiar with
the plugin code though so I might be all wet.
Can you try adding the
At least the tool is running.
The easiest way to verify that the classes were enhanced is to decompile
them and see if they implement the PersistenceCapable interface. Javap works
fine for this.
If your classes do not implement PersistenceCapable, try adding this to
persistence.xml to enable
It looks to me like the unenhanced classes are being loaded with Spring.
Can you use the same jar / class files in a standalone JSE environment?
It might also be good to double check your Spring configuration. You should
not have a LoadTimeWeaver specified when using OpenJPA.
-mike
--
View
Which properties do you have in persistence.xml?
A reply on Nabble (not accepted by the mailing list yet) asserts that this
only happens with slice. If that's the case we can look into reproducing the
problem outside of your container environment.
Thanks
-mike
--
View this message in context:
In general the contents of the entity should match what we get back from the
JDBC driver. I don't think OpenJPA intentionally pads or trims the contents
of a String (although you're seeing otherwise).
That said, DB2 does not differentiate between 'abc' and 'abc '. So
something like this will
Hi,
This is a bug, and was reported in
https://issues.apache.org/jira/browse/OPENJPA-1845 OPENJPA-1845 . The result
of that bug report is to exclude queries that include an IN expression from
the cache with an informative message. This fix went into OpenJPA version
2.1, but not 2.0.
Recently,
Hi Oleg,
I don't think there's a workaround available. This sounds like a good
candidate for an improvement though. Could you open a JIRA
issuehttps://issues.apache.org/jira/browse/OPENJPA,
and vote for it?
The model you listed in your first email to the list should reproduce the
problem, but if
Hi Tim,
Optimistic locking is really intended to work with a 'lighter' isolation
level. The JPA spec itself assumes that you'll be using ReadCommitted.
Near the end of your email (third paragraph from the last one) you're on the
right track. Optimistic locking is intended to avoid database level
Looks correct to me. There's a similar example in
https://fisheye6.atlassian.com/browse/openjpa/tags/2.1.0/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/inheritance/polymorphic/TestTablePerClassInheritanceWithAbstractRoot.java?r=1071316
this testcase (line 203).
-mike
Your query should work, assuming the value for the fivedays is of the
appropriate type (java.sql.Timestamp from what you've said).
If you could post your entities, and table definition to pastebin or
something similar that might help us. Also, which version of OpenJPA and
which database are you
I can help with the different size of the result list.
I think you're seeing https://issues.apache.org/jira/browse/OPENJPA-894
OPENJPA-894 . The first time the results of a FETCH JOIN query are read from
the database OpenJPA only returns the unique rows. Subsequent FETCH JOIN
queries will
class for
its serialization system.
Santa.
Jason Ferguson wrote:
It looks like I have 1.0. I'll try switching over to 2.0 tonight and
let you know.
Jason
On Mon, Apr 11, 2011 at 9:58 AM, Michael Dick
lt;michael.d.d...@gmail.comgt; wrote:
I took another look at the proxy code
The root cause here is that the table was generated with OpenJPA 2.0.1,
which used ABSTIME instead of TIMESTAMP as the column type. The default type
was changed in OPENJPA-1726, and the code that uses the default TS type was
not properly updated. I've updated OPENJPA-1985 with the same info.
A
Hi again,
I'm glad you're making progress, but I'm stumped as to why you're seeing
version 2.1.0 in the error. I was expecting to see something obvious on the
classpath but if it's there I've missed it.
Maybe someone on the list who also has a mac can chime in?
-mike
On Thu, Apr 21, 2011 at
This is a bit of a gray area.. The spec (section 3.5) says :
• In general, the lifecycle method of a portable application should not
invoke EntityManager
or Query operations, access other entity instances, or modify relationships
within the
same persistence context.[43] A lifecycle callback method
Hi Phill,
The snippets from your entities are correct. Which version of OpenJPA are
you using, and how do you do enhancement?
Could the app be picking up an old version of Merchant that doesn't have the
annotation, or an XML mapping file that reset it to a different value?
-mike
On Wed, Apr
Hi Joep,
Can you modify the build.xml file in the simple directory with this (it
should go right after the tag for target name=run It's line 113 in
my copy.
property name=myClasspath refid=classpath/
echo = /echo
echo
Hi Chintan,
This issue might be best handled through the WebSphere support channels.
I'm assuming you changed the
openjpa.jdbc.TransactionIsolationhttp://openjpa.apache.org/builds/latest/docs/manual/manual.html#openjpa.jdbc.TransactionIsolation
persistence property. This has the effect of
Hi Chintan,
Implicit locking is not the same as optimistic locking.
By implicit locking I meant the database locks which are obtained
automatically when you obtain a connection. This level of locking depends on
the isolation level in use. I probably should have referred to it as
isolation level
Bad choice of words and a rushed email on my part.
I was thinking of the pre-compiled binaries from the snapshot
repositoryhttps://repository.apache.org/content/groups/snapshots/org/apache/openjpa/apache-openjpa/2.2.0-SNAPSHOT/apache-openjpa-2.2.0-20110415.075847-49-binary.zip.
The link is near
Hi Chintan,
I'm not very familiar with SQLServer, and I can't recommend a JDBC driver.
It's possible that DataDirect or Microsoft have other workarounds that will
convert a timestamp to another Java type, but it's probably unlikely.
If you cannot introduce a new column it's very hard to do
Hi Joep,
I think there's a problem obtaining a connection - maybe a security setting
that's different for macs? I don't have access to one to try, and
unfortunately the exception closing a connection appears to be hiding the
root cause.
I'll fix the problem with closing a connection and that
Hi Chintan,
We're getting a LockTimeoutException from SQLServer, which is why you're
seeing a different exception.
OpenJPA handles locking on SQLServer a little differently from other
databases. Instead of a FOR UPDATE clause we obtain a table lock.
It would be most helpful if you could enable
In WebSphere you can just enable the trace group openjpa=all and OpenJPA
trace will go to the normal WebSphere trace file.
The trace groups you want are openjpa.jdbc.SQL=all:openjpa.jdbc.JDBC=all.
Here's more on how to enable the trace in WebSphere :
Hi,
I did a quick search through the open issues and there are several reported
problems with cascading. I don't know which one fits your scenario the best.
It would help me (at least) if I could see the test case you mentioned.
I'd recommend either opening a new JIRA and attaching your testcase
Hi Chintan,
Version fields may be of the following types:
int, Integer, short, Short, long, Long, java.sql.Timestamp.
Based on your previous email the MSSQL timestamp should be mapped to a
byte[] which won't work as a version column. If the JDBC driver can map a
timestamp to one of the types
Hi Jason,
Detachment and proxy classes are fairly complicated in OpenJPA. Like Rick
mentioned I've started looking at what it'd take to remove the proxies and
it's turned into a more sizable effort than I'd hoped.
OpenJPA was originally designed with JEE application servers in mind and it
Hi Joep,
You're posting to the right forum. The stack indicates that there's a
problem with a connection. Have you changed anything in the sample related
to the database?
I just downloaded a fresh copy and I wasn't able to reproduce the problem
(Oracle Java 1.6.0_24 on Linux).
-mike
On Mon,
Hi,
I think you're hitting
OPENJPA-1410https://issues.apache.org/jira/browse/OPENJPA-1410.
There's a lot of comments to read through, but I think it boils down to
adding these two
://openjpa.apache.org/builds/2.1.0/apache-openjpa-2.1.0/docs/javadoc/index.html
-mike
On Thu, Apr 7, 2011 at 8:56 AM, Michael Dick michael.d.d...@gmail.com
wrote:
Hi Henno,
Thanks for letting us know. I thought I updated that page after the
release, but I must have missed
Hi Jared,
Currently there is no way to set an OpenJPA specific annotation via XML. We
are working on fixing this, take a look at
OPENJPA-1971https://issues.apache.org/jira/browse/OPENJPA-1971for
the details.
-mike
On Thu, Apr 7, 2011 at 6:12 AM, Jared Pearson jaredapear...@gmail.comwrote:
I'm
Hi Henno,
Thanks for letting us know. I thought I updated that page after the release,
but I must have missed it. The links should be fixed later this morning
(afternoon in the Netherlands).
-mike
On Thu, Apr 7, 2011 at 3:43 AM, Henno Vermeulen he...@huizemolenaar.nlwrote:
Hello,
Maybe you
-SNAPSHOT Javadoc:
http://openjpa.apache.org/builds/apache-openjpa-2.1.1-SNAPSHOT/docs/javadoc/index.html
2.1.0 JavaDoc :
http://openjpa.apache.org/builds/2.1.0/apache-openjpa-2.1.0/docs/javadoc/index.html
-mike
On Thu, Apr 7, 2011 at 8:56 AM, Michael Dick michael.d.d...@gmail.comwrote:
Hi Henno
Hi Chintan,
What you're trying to do is (in my opinion) a gray area. You have a
stateless EJB, but are expecting the EntityManager to track the state of a
set of entities between method calls. If you start a transaction before
calling read() and that transaction is still active when you call
Rick's right, my memory was faulty. I think in the earlier versions of
OpenJPA a refresh was required, but when I ran with a 2.1.1 snapshot this
morning I didn't have to call refresh.
Thanks for keeping me honest Rick..
-mike
On Wed, Apr 6, 2011 at 9:45 AM, Rick Curtis curti...@gmail.com wrote:
I'm going to ask Risk's standard question, how are you doing enhancement?
Can you narrow down the scope of the problem, e.g. does the problem happen
on every insert, or is it something that only happens when the list is
large?
-mike
On Tue, Apr 5, 2011 at 4:28 PM, Jason Ferguson
Hi Chris,
It looks like you're using the openjpa.jdbc.SynchronizeMappings property
(with ForeignKeys=true). Could you verify whether that is the case in your
environment?
This setting is useful during application development, but you probably
don't want to use this setting in your production
Is the MyBase class listed in persistence.xml?
-mike
On Wed, Apr 6, 2011 at 1:54 PM, realdepp thepsy...@freenet.de wrote:
MySQL version is 4.1.22
Connector version is 5.1.8, JDBC version is documented as 4.0
--
View this message in context:
Hi Henno,
Have you set the openjpa.DetachState property or are you using the default
value?
-mike
On Tue, Apr 5, 2011 at 11:17 AM, Henno Vermeulen he...@huizemolenaar.nlwrote:
I suspect this is an issue with detaching!
I turned on the trace and printed a message after entityManager.find.
When you use GenerationType.IDENTITY or GenerationType.SEQUENCE the ID
values aren't known until the row is inserted. OpenJPA does not
automatically refresh this information, but you can obtain it if you use the
EntityManager.refresh() method.
Regarding intialValues, did OpenJPA create the
No problem - we were all new once.
I probably shouldn't have suggested using the same connection as the
EntityManager. Getting the connection from an EntityManager instance is kind
of hack and it will tie you to a specific JPA vendor (OpenJPA in your case).
Generally a better solution when you're
You're welcome.
I belatedly found that we cover getting a connection manually in the user
manual too :
http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_dbsetup_sqlconn
.
-mike
On Thu, Mar 31, 2011 at 6:43 PM, chintan4181 chintan4...@gmail.com wrote:
thanks Michale.
The schema property is not used at compile time.
The easiest way to use a different schema is to use a jta-data-source in
your persistence.xml and set the appropriate schema on the datasource. I
think WebSphere allows the schema to be set as a custom property for their
datasources.
Will the
Hi Tobias,
Which version of OpenJPA are you using?
It looks like we don't have a cached version of the metadata for type B,
enabling
preloadinghttp://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_meta_repositoryof
the meta data might at least work around the problem.
-mike
Hi Chintan,
This has come up before and the net was that we could not support multiple
result sets without some help (or changes) from the specification.
There's a bit more information in
OPENJPA-918https://issues.apache.org/jira/browse/OPENJPA-918,
but unfortunately right now you're best advice
Hi Don,
I'm not familiar with jaxb, but what you have looks pretty close to the
example in the OpenJPA manual.
I've tried to reproduce the non-jaxb path and found that the problem is that
OpenJPA is expecting your XML column to be a VARCHAR (because that's how
it's defined in the entity).
I've
I think this will work
property name=openjpa.Log value=DefaultLevel=WARN, Tool=INFO, SQL=TRACE,
Schema=TRACE /
I suspect it's case sensitive but haven't tried it out.
-mike
On Thu, Mar 24, 2011 at 10:55 AM, Jean-Baptiste BRIAUD -- Novlog
j-b.bri...@novlog.com wrote:
Hi,
I got this in an
On Thu, Mar 24, 2011 at 10:40 AM, Marc Logemann l...@logemann.org wrote:
you are late.
Not really. The code was written two years ago, with a programmatic javac
compiler for debugging ;)
thats not what i meant. I meant in following our discussion on the list ;-)
When i am old and
At one time there was a wiki page with this information (I think), but I
can't find right now.
I did find an old mailing list post that might be a good starting
pointhttp://markmail.org/message/j3nzhnn6pg7uwnk3.
Let us know if this is what you need and we'll see if we can get an up to
date
Hi Krysztof,
I'm not entirely sure how this ever worked for you. The TimeSequence class
does not accept Allocate as a configuration option. I went back and tried
with 2.0.1, 1.2.2, and 2.1.0 and got the error you posted.
Could the openjpa.Schema property have changed when you upgraded?
-mike
1 - 100 of 425 matches
Mail list logo
