|
Re: Addtional Foreign Kry [message #699955 is a reply to message #699813] |
Fri, 22 July 2011 15:58 |
Chris Delahunt Messages: 1389 Registered: July 2009 |
Senior Member |
|
|
Hello Mike,
If you don't want to make object model changes, You can add the constraint to the database yourself, by either modifying the DDL or adding it in after the tables are created. ie:
<property name="eclipselink.ddl-generation.output-mode" value="sql-script"/>
as described here:
http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)#Using_EclipseLink_JPA_Extensions_for_Schema_Generation
The constraint though is not something managed in JPA because it is not mapped. That means the application will need to go to lengths to ensure it is respected - for instance, should the application need to disassociate a language from a service, it will also need to remove all Subscriptions and flush before removing the relationships. JPA will not know that subscriptions are dependent on the service-language relationship and may not remove them first otherwise. The same will need to be done on inserts; the service-language associations made and flushed before Subscriptions added for the same reasons.
The alternative would be to create an Entity for the Service_Language table with its pk being the composite (service_id,language_id). Then Subscription could map directly to it rather than to individual Services and Languages. The relationships would then be managed without need for breaking up transactions into parts, and the object model need not change too drastically - helper methods can be used to transparently return the service_Language components instead of service_language entities, if needed.
Best Regards,
Chris
|
|
|
(no subject) [message #699973 is a reply to message #699813] |
Fri, 22 July 2011 15:58 |
Chris Delahunt Messages: 1389 Registered: July 2009 |
Senior Member |
|
|
Hello Mike,
If you don't want to make object model changes, You can add the constraint to the database yourself, by either modifying the DDL or adding it in after the tables are created. ie:
<property name="eclipselink.ddl-generation.output-mode" value="sql-script"/>
as described here:
http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)#Using_EclipseLink_JPA_Extensions_for_Schema_Generation
The constraint though is not something managed in JPA because it is not mapped. That means the application will need to go to lengths to ensure it is respected - for instance, should the application need to disassociate a language from a service, it will also need to remove all Subscriptions and flush before removing the relationships. JPA will not know that subscriptions are dependent on the service-language relationship and may not remove them first otherwise. The same will need to be done on inserts; the service-language associations made and flushed before Subscriptions added for the same reasons.
The alternative would be to create an Entity for the Service_Language table with its pk being the composite (service_id,language_id). Then Subscription could map directly to it rather than to individual Services and Languages. The relationships would then be managed without need for breaking up transactions into parts, and the object model need not change too drastically - helper methods can be used to transparently return the service_Language components instead of service_language entities, if needed.
Best Regards,
Chris
|
|
|
|
Powered by
FUDForum. Page generated in 0.03444 seconds