OpenJPA tutorial fo r the absolute beginner

[Scott Quint]

IBM WebSphere has just released an Alpha for their implementation of OpenJPA
2.0 for WebSphere and has released a tutorial for beginners. The tutorial is
really for someone that has never used OpenJPA and it really does not
require WebShpere.I know that when I was trying to use OpenJPA for the first
time, I wished I could find a tutorial exactly like this.
http://bit.ly/IBMWASOpenJPATutorial OpenJPA tutorial at IBM Alpha site 

It requires a free registration
-- 
View this message in context: 
http://n2.nabble.com/OpenJPA-tutorial-fo-r-the-absolute-beginner-tp4027822p4027822.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: How work around OpenJPA-1365

[Michael Dick]

Hi Michael,

As I understand it the JPA 2.0 spec is 'effectively' finalized. We're
certainly past the point where a new feature like FetchPlans could be added.


FetchPlans are here to stay with OpenJPA though.

We can bring them up for consideration for the next version of the JPA spec
though.

-mike

On Wed, Nov 18, 2009 at 5:06 AM, Michael Vorburger <
mvorbur...@odyssey-group.com> wrote:

> >>
> http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/
> manual.html#ref_guide_fetch
> > That sounds good, although it's not standard.
>
> But very, very, useful.. ;)  I'm not sure how one can do serious ORM
> without (something like) this; the fetch = FetchType.LAZY / EAGER stuff
> is stuff way too static, IMHO.
>
> Always wondered why this never made it
> (http://www.dataservices-connection.com/2008/09/need-for-fetch-plans.htm
> l) from JDO v2 API
> (http://db.apache.org/jdo/api20/apidocs/javax/jdo/FetchPlan.html) into
> the JPA spec, not even in JPA v2 yet AFAIK.. is there any hope a JPA
> v2.x finally picks this up?
>
>
> -Original Message-
> From: Michael Simons [mailto:michael.sim...@optitool.de]
> Sent: Wednesday, November 18, 2009 11:54 AM
> To: users@openjpa.apache.org
> Subject: Re: How work around OpenJPA-1365
>
> Hi Michael,
>
> Michael Dick schrieb:
> > Hi Michael,
> >
> > Regarding seeing OPENJPA-1365 on 'vanilla' OpenJPA 1.2.1, I'll have to
>
> > take a look at that. It probably happens if the query does not fetch
> > records from the database. If that's what you're seeing then I just
> > need to update the JIRA with that info.
> We are still investigating on this. Please stand by.
>
> >
> > I'm not terribly familiar with JDO. I was under the impression that
> > OpenJPA's FetchPlans were identical (or nearly identical) to those in
> JDO.
> >
> > To use my example (Employee and Manager) you would do something like
> this :
> > OpenJPAEntityManager em = getEntityManager();
> >
> > OpenJPAQuery q = em.createQuery("SELECT m from Manager m ");
> > q.getFetchPlan().addField(Manager.class, "employees");
> >
> > List managers = q.getResultList();
> >
> > There's a lot more in the manual about it, I'd start looking at [1].
> >
> > [1]
>
> >
> > Hope this helps,
> > -mike
> >
> >
> > On Tue, Nov 17, 2009 at 11:02 AM, Michael Simons
> >  >> wrote:
> >
> >> Hi Mike,
> >>
> >> Do you mean fetchplan like described in the manual in chapter 1.7.4?
> >> Or is there a possibility to use JDO-FetchPlan with OpenJPA? If so,
> >> is there a description, how to do that?
> >>
> >> kind regards,
> >> Michael
> >>
> >> Michael Dick schrieb:
> >>> Hi all,
> >>>
> >>> Daryl's correct, the duplicates returned by a JOIN FETCH clause are
> >> correct
> >>> behavior. If you don't want the duplicates to be returned you should
>
> >>> use
> >> the
> >>> DISTINCT keyword and OpenJPA will remove duplicates from the list.
> >>>
> >>> There are several outstanding issues though (which I'm working on):
> >>>
> >>> 1.) OPENJPA-894:  When results are returned from the database
> >>> OpenJPA automatically removes duplicates from the list. If the
> >>> results are
> >> fetched
> >>> from memory the duplicates reappear.
> >>>
> >>> 2.) OPENJPA-1365: After you apply the fix for OPENJPA-894 the
> >>> distinct keyword doesn't work. This is because OpenJPA merely
> >>> prepends the
> >> DISTINCT
> >>> keyword to the SQL generated which doesn't work if you're selecting
> >> across
> >>> multiple tables. Instead we need to filter the result list after
> >> retrieving
> >>> from the database.
> >>>
> >>> There are two proposed fixes for OPENJPA-894 each of which have some
>
> >>> drawbacks.
> >>>
> >>> 3a.) Mike's fix : supports pagination but does not support multiple
> >>> JOIN FETCH statements (ie SELECT m FROM Manager m JOIN FETCH
> >>> m.employees JOIN FETCH m.projects returns the wrong number of
> results).
> >>>
> >>> 3b.) Fay's fix : supported multiple JOIN FETCH statements, but does
> >>> not support pagination (ie query.setMaxResults(),
> >>> query.setFirstResult()
> >> doesn't
> >>> page forward as expected).
> >>>
> >>> So there is work being done, but it's turned out to be a very
> >>> ticklish
> >> issue
> >>> to solve.
> >>>
> >>> At the risk of muddying the waters a bit if you're migrating a JDO
> >>> application have you considered using OpenJPA's FetchPlan
> >>> implementation
> >> to
> >>> eagerly load some fields? Over medium - large datasets I've found
> >>> this to
> >> be
> >>> significantly faster than using a JOIN FETCH, but YMMV.
> >>>
> >>> Hope this helps,
> >>>
> >>> -mike
> >>>
> >>> On Tue, Nov 17, 2009 at 8:48 AM, Daryl Stultz 
> >> wrote:
>  On Tue, Nov 17, 2009 at 9:27 AM, Michael Simons
>  wrote:
> 
> 
> > You state, that you're query with distinct and join fetch does
> > work properly. But this would mean OpenJPA-1365 doesn't occur,
> > does

RE: How work around OpenJPA-1365

[Michael Vorburger]

>>
http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/
manual.html#ref_guide_fetch
> That sounds good, although it's not standard.

But very, very, useful.. ;)  I'm not sure how one can do serious ORM
without (something like) this; the fetch = FetchType.LAZY / EAGER stuff
is stuff way too static, IMHO.

Always wondered why this never made it
(http://www.dataservices-connection.com/2008/09/need-for-fetch-plans.htm
l) from JDO v2 API
(http://db.apache.org/jdo/api20/apidocs/javax/jdo/FetchPlan.html) into
the JPA spec, not even in JPA v2 yet AFAIK.. is there any hope a JPA
v2.x finally picks this up?


-Original Message-
From: Michael Simons [mailto:michael.sim...@optitool.de] 
Sent: Wednesday, November 18, 2009 11:54 AM
To: users@openjpa.apache.org
Subject: Re: How work around OpenJPA-1365

Hi Michael,

Michael Dick schrieb:
> Hi Michael,
> 
> Regarding seeing OPENJPA-1365 on 'vanilla' OpenJPA 1.2.1, I'll have to

> take a look at that. It probably happens if the query does not fetch 
> records from the database. If that's what you're seeing then I just 
> need to update the JIRA with that info.
We are still investigating on this. Please stand by.

> 
> I'm not terribly familiar with JDO. I was under the impression that 
> OpenJPA's FetchPlans were identical (or nearly identical) to those in
JDO.
> 
> To use my example (Employee and Manager) you would do something like
this :
> OpenJPAEntityManager em = getEntityManager();
> 
> OpenJPAQuery q = em.createQuery("SELECT m from Manager m ");
> q.getFetchPlan().addField(Manager.class, "employees");
> 
> List managers = q.getResultList();
> 
> There's a lot more in the manual about it, I'd start looking at [1].
> 
> [1]

> 
> Hope this helps,
> -mike
> 
> 
> On Tue, Nov 17, 2009 at 11:02 AM, Michael Simons 
> > wrote:
> 
>> Hi Mike,
>>
>> Do you mean fetchplan like described in the manual in chapter 1.7.4?
>> Or is there a possibility to use JDO-FetchPlan with OpenJPA? If so, 
>> is there a description, how to do that?
>>
>> kind regards,
>> Michael
>>
>> Michael Dick schrieb:
>>> Hi all,
>>>
>>> Daryl's correct, the duplicates returned by a JOIN FETCH clause are
>> correct
>>> behavior. If you don't want the duplicates to be returned you should

>>> use
>> the
>>> DISTINCT keyword and OpenJPA will remove duplicates from the list.
>>>
>>> There are several outstanding issues though (which I'm working on):
>>>
>>> 1.) OPENJPA-894:  When results are returned from the database 
>>> OpenJPA automatically removes duplicates from the list. If the 
>>> results are
>> fetched
>>> from memory the duplicates reappear.
>>>
>>> 2.) OPENJPA-1365: After you apply the fix for OPENJPA-894 the 
>>> distinct keyword doesn't work. This is because OpenJPA merely 
>>> prepends the
>> DISTINCT
>>> keyword to the SQL generated which doesn't work if you're selecting
>> across
>>> multiple tables. Instead we need to filter the result list after
>> retrieving
>>> from the database.
>>>
>>> There are two proposed fixes for OPENJPA-894 each of which have some

>>> drawbacks.
>>>
>>> 3a.) Mike's fix : supports pagination but does not support multiple 
>>> JOIN FETCH statements (ie SELECT m FROM Manager m JOIN FETCH 
>>> m.employees JOIN FETCH m.projects returns the wrong number of
results).
>>>
>>> 3b.) Fay's fix : supported multiple JOIN FETCH statements, but does 
>>> not support pagination (ie query.setMaxResults(), 
>>> query.setFirstResult()
>> doesn't
>>> page forward as expected).
>>>
>>> So there is work being done, but it's turned out to be a very 
>>> ticklish
>> issue
>>> to solve.
>>>
>>> At the risk of muddying the waters a bit if you're migrating a JDO 
>>> application have you considered using OpenJPA's FetchPlan 
>>> implementation
>> to
>>> eagerly load some fields? Over medium - large datasets I've found 
>>> this to
>> be
>>> significantly faster than using a JOIN FETCH, but YMMV.
>>>
>>> Hope this helps,
>>>
>>> -mike
>>>
>>> On Tue, Nov 17, 2009 at 8:48 AM, Daryl Stultz 
>> wrote:
 On Tue, Nov 17, 2009 at 9:27 AM, Michael Simons
 wrote:


> You state, that you're query with distinct and join fetch does 
> work properly. But this would mean OpenJPA-1365 doesn't occur, 
> does it?
>
 The JIRA states:
 This issue occurs if the proposed fix for OPENJPA-894 is in place.

 So 1365 does not occur unless you've patched your code such that 
 894 is fixed. What version of OpenJPA are you using and do you have

 any patches
>> in
 place?


> When we call "select a from A a join fetch B" we get n instances 
> of A,
 with
> n = numbers of
> A-B-associations.
>
 This is the correct behavior. I have found with OpenJPA 1.2.1, I 
 get distinct rows of A which sounds like what you (and I) want but 
 is
>> improper.
 894 shows that a second run of the query in the same EntityManager
>> yields
 duplicates A's (with LEFT JOIN FETCH). What 

Re: How work around OpenJPA-1365

[Michael Simons]

Hi Michael,

Michael Dick schrieb:
> Hi Michael,
> 
> Regarding seeing OPENJPA-1365 on 'vanilla' OpenJPA 1.2.1, I'll have to take
> a look at that. It probably happens if the query does not fetch records from
> the database. If that's what you're seeing then I just need to update the
> JIRA with that info.
We are still investigating on this. Please stand by.

> 
> I'm not terribly familiar with JDO. I was under the impression that
> OpenJPA's FetchPlans were identical (or nearly identical) to those in JDO.
> 
> To use my example (Employee and Manager) you would do something like this :
> OpenJPAEntityManager em = getEntityManager();
> 
> OpenJPAQuery q = em.createQuery("SELECT m from Manager m ");
> q.getFetchPlan().addField(Manager.class, "employees");
> 
> List managers = q.getResultList();
> 
> There's a lot more in the manual about it, I'd start looking at [1].
> 
> [1]
> http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/manual.html#ref_guide_fetch

That sounds good, although it's not standard.

> 
> Hope this helps,
> -mike
> 
> 
> On Tue, Nov 17, 2009 at 11:02 AM, Michael Simons > wrote:
> 
>> Hi Mike,
>>
>> Do you mean fetchplan like described in the manual in chapter 1.7.4?
>> Or is there a possibility to use JDO-FetchPlan with OpenJPA? If so, is
>> there a description, how
>> to do that?
>>
>> kind regards,
>> Michael
>>
>> Michael Dick schrieb:
>>> Hi all,
>>>
>>> Daryl's correct, the duplicates returned by a JOIN FETCH clause are
>> correct
>>> behavior. If you don't want the duplicates to be returned you should use
>> the
>>> DISTINCT keyword and OpenJPA will remove duplicates from the list.
>>>
>>> There are several outstanding issues though (which I'm working on):
>>>
>>> 1.) OPENJPA-894:  When results are returned from the database OpenJPA
>>> automatically removes duplicates from the list. If the results are
>> fetched
>>> from memory the duplicates reappear.
>>>
>>> 2.) OPENJPA-1365: After you apply the fix for OPENJPA-894 the distinct
>>> keyword doesn't work. This is because OpenJPA merely prepends the
>> DISTINCT
>>> keyword to the SQL generated which doesn't work if you're selecting
>> across
>>> multiple tables. Instead we need to filter the result list after
>> retrieving
>>> from the database.
>>>
>>> There are two proposed fixes for OPENJPA-894 each of which have some
>>> drawbacks.
>>>
>>> 3a.) Mike's fix : supports pagination but does not support multiple JOIN
>>> FETCH statements (ie SELECT m FROM Manager m JOIN FETCH m.employees JOIN
>>> FETCH m.projects returns the wrong number of results).
>>>
>>> 3b.) Fay's fix : supported multiple JOIN FETCH statements, but does not
>>> support pagination (ie query.setMaxResults(), query.setFirstResult()
>> doesn't
>>> page forward as expected).
>>>
>>> So there is work being done, but it's turned out to be a very ticklish
>> issue
>>> to solve.
>>>
>>> At the risk of muddying the waters a bit if you're migrating a JDO
>>> application have you considered using OpenJPA's FetchPlan implementation
>> to
>>> eagerly load some fields? Over medium - large datasets I've found this to
>> be
>>> significantly faster than using a JOIN FETCH, but YMMV.
>>>
>>> Hope this helps,
>>>
>>> -mike
>>>
>>> On Tue, Nov 17, 2009 at 8:48 AM, Daryl Stultz 
>> wrote:
 On Tue, Nov 17, 2009 at 9:27 AM, Michael Simons
 wrote:


> You state, that you're query with distinct and join fetch does work
> properly. But this would
> mean OpenJPA-1365 doesn't occur, does it?
>
 The JIRA states:
 This issue occurs if the proposed fix for OPENJPA-894 is in place.

 So 1365 does not occur unless you've patched your code such that 894 is
 fixed. What version of OpenJPA are you using and do you have any patches
>> in
 place?


> When we call "select a from A a join fetch B" we get n instances of A,
 with
> n = numbers of
> A-B-associations.
>
 This is the correct behavior. I have found with OpenJPA 1.2.1, I get
 distinct rows of A which sounds like what you (and I) want but is
>> improper.
 894 shows that a second run of the query in the same EntityManager
>> yields
 duplicates A's (with LEFT JOIN FETCH). What happens when you do this:

 select distinct a from A a join fetch a.bs
 ?

 How about these two:
 select a from A a left join fetch a.bs
 select distinct a from A a left join fetch a.bs

 I don't want to give the impression that I'm an expert on the matter,
>> just
 that I've dealt with this issue and I want to be sure my understanding
>> of
 things is accurate.

 --
 Daryl Stultz
 _
 6 Degrees Software and Consulting, Inc.
 http://www.6degrees.com
 mailto:da...@6degrees.com

>>
>>
> 

RE: Deleting a persistant object not resulting exception but not deleting the data from database table

[Michael Vorburger]

Balu,

Your description isn't very clear, your "making the object persistant"
using findById?!  and your remove() results in an
"IllegalArgumentException: Removing a detached instance" or "does not
result any exception" ?

If you ARE trying to do em.remove() on a detached entity, what may work
(I have not tried it) is to use a
getJpaTemplate().remove(getJpaTemplate().getReference(EmailerSchedulerEn
tity.class, emailerScheduler.getId())) kind of approach.

Regards.
 

-Original Message-
From: baluji [mailto:jaish...@gmail.com] 
Sent: Wednesday, November 18, 2009 8:35 AM
To: users@openjpa.apache.org
Subject: Deleting a persistant object not resulting exception but not
deleting the data from database table


   hi,


I am trying delete a detached instance resulting 

Caused by: java.lang.IllegalArgumentException: Removing a detached
instance

I am making the object persistant by using the method

emailerScheduler= this.findById(emailScheduler.getId());

validating whether the object is persistant by using the following
method that returns true.

  
getJpaTemplate().contains(emailerScheduler);


and then removing the object 

   getJpaTemplate().remove(emailerScheduler);

this does not result any exception.But it does not result deletion
of the data from database.

   any help will be  appreciated.

Thanks

Balu

--
View this message in context:
http://n2.nabble.com/Deleting-a-persistant-object-not-resulting-exceptio
n-but-not-deleting-the-data-from-database-table-tp4023833p4023833.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.



• This email and any files transmitted with it are CONFIDENTIAL and intended
  solely for the use of the individual or entity to which they are addressed.
• Any unauthorized copying, disclosure, or distribution of the material within
  this email is strictly forbidden.
• Any views or opinions presented within this e-mail are solely those of the
  author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
• An electronic message is not binding on its sender. Any message referring to
  a binding engagement must be confirmed in writing and duly signed.
• If you have received this email in error, please notify the sender immediately
  and delete the original.

RE: Generate .java Files from ora.xml?

[Michael Vorburger]

Thomas, 

I think you would have to hack this yourself.. probably using any
Template Engine (http://de.wikipedia.org/wiki/Template_Engine) such as
e.g.  http://freemarker.sourceforge.net/, or
http://wiki.eclipse.org/Xpand.  

For example, we (at work) have built a fairly extensive generator of
.java JPA Entity classes, from some older in-house model (not an ora.xml
like you are looking for) using Xpand.  As have many others of course,
e.g. http://www.fornax-platform.org/ may interest you.

Regards,

Michael Vorburger
Development Manager, Design Studio
Odyssey Financial Technologies


-Original Message-
From: Thomas Polliard [mailto:tho...@polliard.com] 
Sent: Wednesday, November 18, 2009 1:42 AM
To: users@openjpa.apache.org
Subject: Generate .java Files from ora.xml?


I have scoured the documentation and I see that the MappingTool works
for creating schema and the Reverse takes a schema and generates .java
files but if I create the ora.xml file and put my mappings in their then
is there no way to generate the .java files from it.  This would put the
mapping into one place and would only require a codegen from ora.xml and
schema-create from ora.xml.  This would keep the mappings in one place
and allow there to be no disconnect from mappings.

Thanks

Thomas Polliard
--
View this message in context:
http://n2.nabble.com/Generate-java-Files-from-ora-xml-tp4022362p4022362.
html
Sent from the OpenJPA Users mailing list archive at Nabble.com.



• This email and any files transmitted with it are CONFIDENTIAL and intended
  solely for the use of the individual or entity to which they are addressed.
• Any unauthorized copying, disclosure, or distribution of the material within
  this email is strictly forbidden.
• Any views or opinions presented within this e-mail are solely those of the
  author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
• An electronic message is not binding on its sender. Any message referring to
  a binding engagement must be confirmed in writing and duly signed.
• If you have received this email in error, please notify the sender immediately
  and delete the original.