|
| Re: Single table inheritance: Using foreign key as discrimination values [message #1708670 is a reply to message #1708364] |
Fri, 18 September 2015 14:36  |
 Chris Delahunt
Messages: 1389
Registered: July 2009 |
Senior Member |
|
|
I wouldn't use java inheritance for what you've just shown. An Employee can have the developer role, a manager role, or a QA role, so I would make the Employee reference a Type entity and just use it like that. This allows an Employee to change roles later on, something that you can't to do with Java inheritance: a QA subclass cannot be changed into a Manager subclass, and would have to be deleted and recreated as a Manager, while this way, any Employee with a developer type role can just change roles to a manager type role.
If there is only 1 developer type record, and if they really are static and tied to inheritance, then you would have two mappings to the same field. Use the foreign key as the discriminator, and the 1:1 mapping to the type with the join column marked as insertable=false, updatable=false so that it is read-only and can never be changed. It shouldn't matter if you use the developer string or the foreign key value if they really are static. I'm guessing this won't work for your model though.
If each employee has its own record in the employee_types table, then the Employee entity can use this table as a secondary table. This doesn't quite match what you have though, as this requires a strict 1:1, and generally uses the same ID values for both, with the ID in the secondary table controlled by the value in the primary table - this allows sequencing to be used, and prevents conflicts.
If your table is more complex, such that a developer Mark might have a different description from Developer Peter:
employee_types
id role description
1 developer 'writes code'
4 developer 'reviews code'
But still need 3 distinct Employee class types for reasons you haven't shown, then you need something more complex then regular JPA inheritance. EclipseLink gives you the option to define your own way to decide what an Entity's class type should be using the ClassExtractor: http://www.eclipse.org/eclipselink/documentation/2.4/jpa/extensions/a_classextractor.htm This still may need you to force a join between the two tables so that the 'role' string is available when the Employee instances are being built, so that your class extractor method has all the info it needs to build the correct type.
Hope this helps.
Chris
[Updated on: Fri, 18 September 2015 14:43] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.02693 seconds
] 
Search
Help
Register
Login
Home
