Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of plunchete@gmail.com
 designates 66.249.92.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=dDg336hXpI+KsAfMJq9XeubuKDCP37jP8yiB98b1bPWJf5H3BfWkBuB7eEQL2M86Mi
         zywXbkG0+VemBtVu6KYWYJqJOR3sVZQ6Ii9lQ35x2UBTXR6WiaaL2LbXp4Y5m1S3R8zE
         kg+sKJNOwKzi9KhbcZT5p9nB32lIgI6h+TrU4=
Message-ID: <41fba98d0807080503s238b80a9k5eb432903abce460@mail.gmail.com>
Date: Tue, 8 Jul 2008 14:03:42 +0200
From: "Ignacio Andreu" <plunchete@gmail.com>
To: users@openjpa.apache.org
Subject: Re: EAGER vs. LAZY loading - weird behaviour in OpenJPA 1.0.1
In-Reply-To: <1215518196063-364201.post@n2.nabble.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_15529_23245397.1215518622619"
References: <1215518196063-364201.post@n2.nabble.com>

------=_Part_15529_23245397.1215518622619
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

As far as I know, if you use the eager strategy is normal that OpenJPA
generates queries to load the diferent relations from the database. If you
use lazy strategy OpenJPA only loads the relations when they are acceded, of
course if you are handling the PersistentContext for your own and you closed
it before the access it will be null.

On Tue, Jul 8, 2008 at 1:56 PM, Beniamin Mazan <it@mazan.pl> wrote:

>
> Hi
> I refactored my source code quoted in
> http://n2.nabble.com/Incredible-set-of-statements-td221053.html
> Currently I use:
>
> @Entity
> public class Customer {
> ...
>        @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER,
> mappedBy =
> "customer")
>        private Set<Product> products = new HashSet<Product>();
> ...
> }
>
> @Entity
> public class Product {
> ...
>    @ManyToOne(cascade = { CascadeType.MERGE, CascadeType.REFRESH }, fetch =
> FetchType.EAGER)
>    @JoinColumn(name = "billacc_id", nullable = false)
>    Customer customer;
>
>    @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy
> = "product")
>    @OrderBy(value = "created DESC")
>    private List<RequestLog> logs = new ArrayList<RequestLog>();
> ...
> }
>
> @Entity
> public class RequestLog {
> ...
>        @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch
> =
> FetchType.LAZY)
>        @JoinColumn(name = "product_id", nullable = false)
>        private Product product;
>
>        @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER,
> mappedBy =
> "request")
>        @OrderBy(value = "created DESC")
>        private List<ResponseLog> children = new ArrayList<ResponseLog>();
> ...
> }
>
> @Entity
> public class ResponseLog {
> ...
>        @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch
> =
> FetchType.LAZY)
>        @JoinColumn(name = "request_id", nullable = false)
>        private RequestLog request;
> ...
> }
>
> I've noticed 2 cases of outlandish manner.
>
> 1) When I use finder for Customer or Product (with RequestLog.product using
> fetchType == LAZY) I got initialized structure with all RequestLogs'
> references to Products set to null
>
> 2) When I use finder for Customer or Product (with RequestLog.product using
> getchType == EAGER) I see that OpenJPA generate queries to get Customer,
> Product, RequestLog from DB, but queries for RequestLogs are joins using
> all
> classes from bottom to up - (request_log, product and customer) despite the
> fact, that EM has gathered these data in previous queries and could use it
> instead of redundant selecting them from DB.
>
> Is it usual OpenJPA behaviour?
>
> -----
> thanks, Beniamin
> My homesite -  http://www.mazan.pl http://www.mazan.pl
> --
> View this message in context:
> http://n2.nabble.com/EAGER-vs.-LAZY-loading---weird-behaviour-in-OpenJPA-1.0.1-tp364201p364201.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>

------=_Part_15529_23245397.1215518622619--