Re: Build time enhancement or GlassFish enhancement?
As suspected something strange with the class loaded and entities (POJOs) used in a web service... Stripped the openjpa jar to PersistenceCapable.class, put that into ear -> worked -- View this message in context: http://openjpa.208410.n2.nabble.com/Build-time-enhancement-or-GlassFish-enhancement-tp6061774p6086146.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
How to Specify the Schema for a Named Query
Hi,
I am using Apache Derby with OpenJPA and have a class with a named query.
Unfortunately, every time I attempt to execute the named query I get an
error because OpenJPA is assuming the "USER" schema. The "USER" schema is
not the default for Derby. It is "APP" I think. This does not happen when
I do not use a named query.
Here are my persistence.xml properties:
openjpa.ConnectionURL=jdbc:derby:databases/JPATest;create=true
openjpa.ConnectionUserName=user
openjpa.ConnectionPassword=password
openjpa.ConnectionDriverName=org.apache.derby.jdbc.EmbeddedDriver
openjpa.jdbc.Schema=APP
openjpa.jdbc.SynchronizeMappings=buildSchema(SchemaAction='add,deleteTableContents')
Here is my first test with a native query...
@Entity
@NamedNativeQuery(name = "getByID",
resultClass = com.mycompany.Employee.class,
query = "SELECT x FROM Employee x WHERE x.id = ?1")
@Cacheable
@Table(schema = "APP")
public class Employee{
Here is the code to execute the query:
Query q = em.createNamedQuery("getByID");
q.setParameter(1, rand);
Here is the error:
Exception in thread "main"
org.apache.openjpa.persistence.PersistenceException: Schema 'USER' does not
exist {SELECT x FROM Employee x WHERE x.id = ?} [code=3, state=42Y07]
--
View this message in context:
http://openjpa.208410.n2.nabble.com/How-to-Specify-the-Schema-for-a-Named-Query-tp6085743p6085743.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: OneToMany cascading persist and sequence ID generator
No problem. I'm happy to hear that you are up and running. -Jeremy On Wed, Mar 2, 2011 at 11:26 PM, Phill wrote: > Many thanks Jeremy, to my embarrassment I've discovered that lead wasn't > getting set properly on the other end of the association. I jumped to the > wrong conclusion about the id generation not working... sorry for taking up > your time with this. > > On 02/mar/2011, at 21.42, Jeremy Bauer wrote: > > > Hi Phill, > > > > I tried a similar configuration, but was unable to reproduce the failure. > > Since cascade is defined on the Lead-side of the relationship, I'm > assuming > > that you are persisting the Lead entity, right? I'm also assuming that > > you've set all bi-directional references in your code. ie > > answer.setLead(lead), lead.setAnswers(answers). If both of those > > assumptions are correct, the next step would be to provide an OpenJPA > trace > > using: > > > > > > > > please enable parameter value trace as well using: > > > > > value="PrintParameters=true"/> > > > > That may help us spot the problem. Or, if possible, please provide a > simple > > test that can be used to reproduce the problem. > > > > -Jeremy > > > > On Wed, Mar 2, 2011 at 11:08 AM, Phill wrote: > > > >> Yes it also uses a sequence generator. > >> > >> SurveyAnswer.java > >> > >> @SequenceGenerator(name = "Survey_Result_Id_Gen", sequenceName = > >> "survey_result_seq", allocationSize = 10) > >> > >> @Id > >> @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = > >> "Survey_Result_Id_Gen") > >> @Column(name = "result_id") > >> protected long id; > >> > >> > >> On 02/mar/2011, at 17.24, Jeremy Bauer wrote: > >> > >>> Thanks, Phill. Sorry, I forgot to ask - does SurveyAnswer also use the > >> same > >>> id generation strategy as Lead? In the meantime, I'll begin trying to > >>> reproduce the failure you are seeing. > >>> > >>> -Jeremy > >>> > >>> On Wed, Mar 2, 2011 at 9:26 AM, Phill wrote: > >>> > OpenJPA 2.1.0 and PostgreSQL 9 > I have separate DDL. > Phill > > > On 02/mar/2011, at 16.22, Jeremy Bauer wrote: > > > Hi Phill, > > > > What database and version of OpenJPA are you using? Also, does > OpenJPA > > generate the tables or do you have separate DDL? > > > > -Jeremy > >> > >
Re: same jpa query generates different SQLs
Hi,
created an issue for it. Thanks for your ideas to make the cache disablement
query based
---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de
Am 02.03.2011 um 19:10 schrieb Jeremy Bauer:
> Marc,
>
> I'm glad that worked for you. You could actually just exclude that query
> for the time being, that way you still get caching benefits for your other
> statements. To exclude the query you can either set the query hint via
> query.setHint("openjpa.hint.IgnorePreparedQuery", true) on the query or
> exclude it via persistence property:
>
> value="true(excludes='select o FROM Order o where o.createdYmd = ?1
> order by o.id')"/>
>
> You can get more specifics on cache exclusion in this section of the OpenJPA
> manual[1].
>
> That should get you by for the time being, but please open a JIRA for this
> problem so that it gets fixed.
>
> [1]
> http://openjpa.apache.org/builds/latest/docs/manual/ref_guide_cache_querysql.html
>
> -Jeremy
>
> On Wed, Mar 2, 2011 at 10:51 AM, Marc Logemann wrote:
>
>> Hi Jeremy,
>>
>> thanks for your instant feedback. I directly tried your suggestion and now
>> it works. So there is a bug in the cache implementation with regard to Type
>> Mappings.
>> And its not a DB2 thingy because i am using MySQL ;-)
>>
>> if you need more infos in the error case, i am willing to help if you
>> want I would like to see this solved because disabling the cache means
>> decreasing the performance somehow right?
>>
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>>
>>
>>
>>
>> Am 02.03.2011 um 17:31 schrieb Jeremy Bauer:
>>
>>> Hi Marc,
>>>
>>> I'm wondering if this isn't caused by an inconsistent parameter type
>> mapping
>>> as a result of using the QuerySQLCache. I saw a similar issue a few weeks
>>> ago, but it was oddly specific to DB2 on zOS. Please try:
>>>
>>>
>>>
>>> -Jeremy
>>>
>>> On Wed, Mar 2, 2011 at 9:43 AM, Marc Logemann wrote:
>>>
Hi,
i am totally astonished:
I am using this query:
public List findByDate(Date date) {
TypedQuery query = getEntityManager().
createQuery("select o FROM Order o where o.createdYmd = ?1
order by o.id", Order.class);
query.setParameter(1, date, TemporalType.DATE);
return query.getResultList();
}
This query is called by a service class which is scheduled ever 30
>> seconds.
See the caller:
// get yesterdays Date
Date today = new Date();
Calendar calendar = Calendar.getInstance();
calendar.setTime(today);
calendar.add(Calendar.DATE, -1);
Date yesterday = calendar.getTime();
List list = orderDao.findByDate(yesterday);
Now, on the second run, the query parameter is of type timestamp with
>> full
time specified, giving me 0 records of course. First query returns
>> records
because there TemporalType seems to work. See log.
FIRST RUN ->
[DEBUG myScheduler-3 16:36:30] | executing
prepstmnt 1488869003 SELECT t0.oid, t0.`_version`, t1.oid,
>> t1.`_version`,
t1.cleared, t1.id, t1.lastused, t2.oid, t2.`_version`, t2.created,
t2.createdymd, t2.custnr, t2.greenoption, t2.ordernr, t2.invaddress_oid,
t2.iscardowner, t2.cost, t2.currency, t2.pricing, t2.paymenttype,
t2.printed, t2.printedby, t2.totalprice, t1.boxtype, t0.created,
t0.createdymd, t0.custnr, t3.oid, t3.jpatype, t3.`_version`,
>> t3.addresstype,
t3.city, t3.company, t3.country, t3.department, t3.email, t3.firstname,
t3.gender, t3.lastname, t3.middlename, t3.phone, t3.zip,
>> t3.postofficebox,
t3.street, t3.housenr, t3.title, t3.deliverymode, t0.greenoption,
t0.ordernr, t4.oid, t4.jpatype, t4.`_version`, t4.addresstype, t4.city,
t4.company, t4.country, t4.department, t4.email, t4.firstname,
>> t4.gender,
t4.lastname, t4.middlename, t4.phone, t4.zip, t4.postofficebox,
>> t4.street,
t4.housenr, t4.title, t4.deliverymode, t4.order_oid, t0.iscardowner,
t0.cost, t0.currency, t0.pricing, t0.paymenttype, t0.printed,
>> t0.printedby,
t0.totalprice FROM orders t0 LEFT OUTER JOIN boxes t1 ON t0.box_oid =
>> t1.oid
LEFT OUTER JOIN address t3 ON t0.oid = t3.order_oid LEFT OUTER JOIN
>> address
t4 ON t0.invaddress_oid = t4.oid LEFT OUTER JOIN orders t2 ON t1.oid =
t2.box_oid WHERE (t0.createdymd = ?) AND (t3.jpatype IS NULL OR
>> t3.jpatype
IN (?)) ORDER BY t0.ordernr ASC [params=(Date) 2011-03-01, (int) 2]
SECOND RUN ->
[DEBUG myScheduler-2 16:37:00] |
>> executing
prepstmnt 154018541 SELECT t0.oid, t0.`_version`, t1.oid, t1.`_version`,
t1.cleared, t1.id, t1.lastused, t2.oid, t2.`_version`, t2.created,
t2.createdymd, t2.custnr, t2.greenoption, t2.ordernr, t2.invaddress_oid,
t2.iscardowner, t2.cost, t2.currency, t2.pricing, t2.paymentt
Re: 2.1.0 from maven repository woes
Yes, I've been using build time enhancement - runtime was there for fast prototyping in rare cases build time enhancement did not run for whatever reason. I removed it as you suggested to be consistent always. Thanks! Krzysztof -- View this message in context: http://openjpa.208410.n2.nabble.com/2-1-0-jars-from-maven-repository-cause-EntityManagerFactory-initialisation-problems-tp6077834p6084079.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: 2.1.0 from maven repository woes
Hello Michael,
Big thanks for the hints - yes it's bizzare it worked this way indeed. One
explanation could be I was switching to "table" generator for Postgres
sometimes as there was some problem with sequence removal during schema
cleanup ("drop" action).
But I had used this sequence definition before successfully, I had
impression.
Best regards,
Krzysztof
--
View this message in context:
http://openjpa.208410.n2.nabble.com/2-1-0-jars-from-maven-repository-cause-EntityManagerFactory-initialisation-problems-tp6077834p6084069.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
