-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: Using twice the same persistent data in different classes
PostPosted: Wed Nov 21, 2007 8:54 am 
Newbie

Joined: Tue Nov 20, 2007 4:16 pm
Posts: 2
Hello!

I'm considering using Hibernate, so i'd like to know whether it supports using data from the same table in different persistent classes without creating it twice in memory.
For example:
I've got to database tables, PERSON and ADDRESS, which are related by ADDRESSID. So i create two persistence classes:

class Person
{
Address a;
...
}

class Address
{
...
}

and map them properly.
But also i need (for representation) class like Person-with-address, which contains fields from both tables.
As far as i learnt from documentation, i can map it using <join> tag. But then this new class won't have relations to classes Person and Address, therefore some data frome these DB tables would be created in memory at least twice.
Is there any way I can create class 'Person-with-address', having it persisted in database but with links to Preson and Address, like

class Person_with_address
{
Address a;
Person p;
...
}
,so if 'a' and 'p' have been fetched from DB, Person_with_address will not execute any queries? I need all three classes. Maybe <dynamic-component> can help me here, but I don't see how.
I hope you understand what i meant.


Top
 Profile  
 
 Post subject: Short answer, yes...
PostPosted: Wed Nov 21, 2007 4:11 pm 
Newbie

Joined: Thu Nov 15, 2007 1:36 pm
Posts: 12
Location: Ahsburn, VA
If Hibernate already has the object loaded, you're not going to get an additional query happening - it's very smart.

However, I'd start to call into question your object model if you're going to having a lot of PersonWithAddress.Address equaling PersonWithAddress.Person.Address. This make sense if home/shipping/billing are different addresses, though.

In a larger view, from one Hibernate newbie to another, you might enjoy this piece of insight I gleaned.

My first thoughts in using Hibernate when I started many months ago was that I'd do all my database design and then try to mush Hibernate over it. Doing it that way was awful.

Seriously, don't think about the database. Think about the object model.

Code:
@Entity
class Address { ... }

@Entity
class Person {
  Address address;
}

@Entity
class PersonWithAddress {
  Person person;
  Address address;
}


Then generate your schema. What you'll find is that Hibernate does not just the right thing, but the efficient thing, often coming up with a better, tighter DDL solution that you'd do by hand.

Each entity, in the case above, has its own life-cycle, and is managed by foreign keys. A couple of annotations later and you can have cascading deletes.

Bottom line: yes, Hibernate will do what you want. In fact, it will be almost magical with its database optimizations.

-wls


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 22, 2007 7:34 am 
Newbie

Joined: Tue Nov 20, 2007 4:16 pm
Posts: 2
Thanks for your answer, i think this is just what i want


Top
 Profile  
 
 Post subject: ...please remember to rank
PostPosted: Thu Nov 22, 2007 5:14 pm 
Newbie

Joined: Thu Nov 15, 2007 1:36 pm
Posts: 12
Location: Ahsburn, VA
Please remember to rank helpful messages so that people can earn credits to ask questions of their own.

Thanks!


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.