Re: Hibernate mapping for sql join
- From: Arved Sandstrom <asandstrom3minus1@xxxxxxxxxxx>
- Date: Sat, 12 Mar 2011 10:51:31 -0400
On 11-03-12 09:22 AM, Stefanie Ertheld wrote:
On 11 Mrz., 20:50, Tom Anderson <t...@xxxxxxxxxxxxxxx> wrote:
On Fri, 11 Mar 2011, Peter Horlock wrote:
however, could you be a bit more specific?
Throwing this at Google:
Gives me its hugh reference:
This might be marginally preferable:
However doesn't (easily) answer my problem at hand.
Huh? The example in the document you posted is this:
SELECT NEW com.company.PublisherInfo(pub.id, pub.revenue, mag.price)
FROM Publisher pub JOIN pub.magazines mag WHERE mag.price > 5.00
Your desired query is this:
select e.name, d.depName from employee e join deparment d on (e.depNo = d.depNo)
Are you saying you don't see any resemblance at all?
Okay, I guess now I got it! ;-)
However, it seems like you need an "EventManager" instance for it to
and I read it was something like the Session / SessionManager, or
something "above" it.
Currently we have Spring managing the Hibernate Session - and it was
said the EventManager could be
wirred into Spring too - but is it possible to have both Session and
When I said I don't want to do it in HQL, I meant because I know pure
But now that you come up with JPL - this seems even more complicated.
Couldn't it be done with HQL too? The Pojo I am using i have wired
into Hibernate with a mapping -
it's just a special, flat mapping without any reference to other
OK, I see where you're coming from a bit more clearly. For background,
JPA is the standard Java EE persistence API, and it describes/defines
JPQL - the Java Persistence Query Language. Think of JPA as an ORM
abstraction that persistence providers like Hibernate and
Toplink/EclipseLink support. Hibernate and EclipseLink still retain
their own native ORM APIs.
JPQL is actually a subset of HQL as of Hibernate 3, and in any case has
always looked like HQL a lot.
Now, if you're using Hibernate, but _not_ the JPA layer supported by
Hibernate (since it is a JPA provider as well), that's cool. I'm no
expert on Hibernate, and in fact when I use EclipseLink I don't use the
native APIs unless there's a really good reason to. So I don't know all
the nooks and crannies of the Hibernate native APIs. But one possibility
is using native SQL in your Hibernate queries and applying a result
transformer. This is similar to iBatis result maps as near as I can tell.
As a side note, I'm guessing Hibernate Session here means a client (as
opposed to server) session, in which case *if* you were using JPA - and
I'm not saying you should - a Session would back up a JPA EntityManager.
The user's going to pick dancing pigs over security every time.
-- Bruce Schneier
- Prev by Date: Re: Java’s Future Lies In Mobile?
- Next by Date: Re: Java’s Future Lies In Mobile?
- Previous by thread: Re: Hibernate mapping for sql join
- Next by thread: Re: Hibernate mapping for sql join