• 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 ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

Use of @SecondaryTable in EJB3.0

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

I am bit confused with @SecondaryTable annotation in EJB3.0. By its definition, i understood that, if the data need to be stored across
multiple tables then we have to use @SecondaryTable annotation. Anyway, we have to have different setters and getters for those fields whichever are needed to store in the database table given in the @SecondaryTable annotation. And the fields which were mapped to other table using @Column(name = "AGE", table="EMPLOYEE_AGE") are anyway not saved in the primary entity say EMPLOYEE. Then what is the difference of storing the data into different tables using other child entities and using @SecondaryTable annotation?

Instead of keep all setters and getters which are meant for different table in the same entity, why cant we use seperate entities to store the data into that particular table which is mapped to that particular entity?

Note: EMPLOYEE is Primary Table and EMPLOYEE_AGE is secondary table.

Pls clarify.
Posts: 304
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The difference is in the modelling of your entities. You could just as easily break the one entity into two entities and have a relationship between them, but here are some questions that you should pose to your object model (EMPLOYEE/EMPLOYEE_AGE in your case) to influence you one way or the other:

- Are they always operated on together or do you have a reason to encapsulate them separately as to objects?

- Does the second entity (EMPLOYEE_AGE) have its own identity? Will it ever be created independently from the EMPLOYEE, or are they alrways created/deleted together?

- Is there ever any need to query against the EMPLOYEE_AGE without going through the EMPLOYEE?

- Do you ever want to not load EMPLOYEE_AGE, i.e. if you had a relationship are there times when you would want to lazily load it?

The answers to these and other entity modeling questions would determine whether you should make them one entity or two (or possibly even an embedded object).
Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic