You cannot programatically set the eager/lazy setting. You either set it to
EAGER and have it always fetch, or you set it to lazy and for those things
(like servlets) that need to force an eager fetch, they would need to call into
some SLSB or some such thing that performs a FETCH JOIN query.
"[EMAIL PROTECTED]" wrote : You cannot programatically set the eager/lazy
setting. You either set it to EAGER and have it always fetch, or you set it to
lazy and for those things (like servlets) that need to force an eager fetch,
they would need to call into some SLSB or some such thing that pe
There's a lot of resources on the 'net that explain FETCH JOINs and its syntax.
Bill Burke's EJB3 book also has a chapter on JPA Queries that is good.
Google "FETCH JOIN". e.g. Here's a hibernate page that may be helpful.
http://www.hibernate.org/hib_docs/reference/en/html/queryhql.html
View t
OK, thanx. So I got this thingy working.
But now I have something like this, which also gives me an error, that the
items are not yet fetched ...
| Itemgroup myItemGroup =
getItemDispatcher().findItemGroup(Integer.parseInt(request.getParameter("id")));
|
| Collection myig = myItemGroup.
So, Itemgroup has an items relationship that is lazy loaded. Your
findItemGroup is only loading in the Itemgroup entity without doing any fetch
joining or eagerly loading of that relationship, hence your error.
you will need to have another method, "findItemGroupWithItems" or something
like th
"[EMAIL PROTECTED]" wrote : So, Itemgroup has an items relationship that is
lazy loaded. Your findItemGroup is only loading in the Itemgroup entity
without doing any fetch joining or eagerly loading of that relationship, hence
your error.
well, but I though when I access the items-collection t
Every time you call "find" you are getting back a new attached instance
initialized according to the lazy-loading properties of your entity, i.e. it
will not have any relationship info that is set to LAZY. Even if you called
that method from that servlet before. I believe the same behavior occ
I see ... even though I'm not 100% satisfied with this answer :). As you
figured, I wouold like to have a better integration into the presentation-layer.
Then again: I'm currently working on a research-project, where I want to
compare two different web-application-platforms (java vs. php), so I'
but wait ... when I'm using SFSB and I make repeated calls, wouldn't that be
like making those calls all from the same session bean? I mean ... I though
using a SFSB in conjunction with an extended entity-manager should avoid that
entities get detached.
View the original post :
http://www.jbos
using extended persistence contexts can work also - which is how JBoss Seam
does it, I believe.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021228#4021228
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021228
__
well ... seems not. Or I'm doing something wrong :(
That's what I read in some book, that using extened persistence and SFSB should
overcome the problem of detaching entities.
hmm ...
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021254#4021254
Reply to th
Another way I found useful was using the OOP concepts to load the mappings or
just the core table vlaues.
Have the main table mapped in the superclass and the mappings that you want to
load sometimes in the subclass.
e.g. If the table name is Customer.
have 2 entities Customer, and Customer
Another way I found useful was using the OOP concepts to load the mappings or
just the core table vlaues.
Have the main table mapped in the superclass and the mappings that you want to
load sometimes in the subclass.
e.g. If the table name is Customer.
have 2 entities Customer, and CustomerWi
13 matches
Mail list logo
