• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JPA-Hibernate. Repeated column in mapping for entity.

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I might have a design problem, so first of all I would like to explain the design.

Imagine I have a conference with 3 kind of speakers. So I have the entity Conference and the entity Speaker.

The entity Speaker has 3 attributes: speaker1, speaker2 and speaker3 of the entity Speaker. The way I've mapped this is the following.

@Entity
@Table(name = "SPEAKERS")
public class Speaker
{
@Id
@Column(name = "ID_SPEAKER")
private Long idSpeaker;

//other fields like name, etc...

// getter and setter
}


@Entity
@Table(name = "CONFERENCES")
public class Speaker
{
@Id
@Column(name = "ID_CONFERENCE")
private Long idConference;

@ManyToOne
@JoinColumn(name = "ID_SPEAKER")
private Speaker speaker1

@ManyToOne
@JoinColumn(name = "ID_SPEAKER")
private Speaker speaker2

@ManyToOne
@JoinColumn(name = "ID_SPEAKER")
private Speaker speaker3

// getters and setters
}

If I do this, I get the org.hibernate.MappingException: Repeated column in mapping for entity..........

What would be the proper design for such issue? Inheritance?

Thank you very much.
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd map conference speaker as a seperate entity. What do you do when your conference changes to having four speakers?
 
Berti Yo
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think I need this kind of mapping. That was just an example. I'll try to put another example.

Imagine you have the entity Project, and the entity User. The users can create, modify and/or be responsible for a project, and I want to store who created the project, who was the last one who modified it, and who is the responsible. The database model would be something like:

User
ID_USER (PK)
NAME
....


Project
ID_PROJECT (PK)
ID_USERCREATOR (FK pointing to ID_USER)
ID_USER_MODIFIER (FK pointing to ID_USER)
ID_USER_RESPONSIBLE (FK pointing to ID_USER)

I would have the following classes

@Entity
@Table(name = "USER")
public class User
{
@Id
@Column(name = "ID_USER")
private Long idUser;

//other fields like name, etc...

// getter and setter
}


@Entity
@Table(name = "PROJECT")
public class Project
{
@Id
@Column(name = "ID_PROJECT")
private Long idProject;

@ManyToOne
@JoinColumn(name = "ID_USER")
private User userCreator;

@ManyToOne
@JoinColumn(name = "ID_USER")
private User userModifier;

@ManyToOne
@JoinColumn(name = "ID_USER")
private User userResponsible;


// getters and setters
}



Do you still think I need another design? What do you mean with "conference speaker as a separate entity" ?? Do you mean three entites? I first thought, as the first solution, of a one-to-many relationship: one conference has some speakers. But, what if I want to differenciate the speakers because the have three diferent functions?

Could you be more explicit with your solution?

Thank you for your answer.


 
Paul Sturrock
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Alarm bells ring in my head when I see attributes of the same type repeated on one entity, it always comes back to bite when another relationship needs described and the schema has become difficult to migrate. That's not to say its always a cast iron rule, just something I'm always aware of. What I'd do in your Conference -> Speaker example is change it so you have a Conference entity, a Speaker entity and ConferenceSpeaker entity that maps the relationship between a Speaker and a Conference. Once you do this it becomes clearer where the attribute "speaker order" should go and allows you to create Conferences with zero to n Speakers without having to change your data model. If you are worried about not having two Speaker 1s at Conference A you can use unique constraints to prevent this.

Likewise with your Project example, how do you use the entity as your defined it if two Users asume co-responsibility for a single Project? This could be remodelled to have an entity called Project, one called User and another called ProjectUserRole, which again maps and describes the relationship between a Project and User(s).

You don't have to go this route - I only bring it up as something to consider. If you want to keep your data model as is you need to be aware that the "name" of the join column refers to the attribute of the mapped entity, not the key on the associated entity. So you would need to join on three differernt attributes of Conference (say, speaker_1_id, speaker_2_id and speaker_3_id) rather than trying to define one attribute that describes three associations - which is of course impossible.



 
Berti Yo
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Thank you very much. You've convinced me. Definitevely your solution can give all the functionality and is much more flexible.

Thanks again.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic