| Addtional Foreign Kry [message #699813] |
Fri, 22 July 2011 07:12  |
Eclipse User |
|
|
|
Hi,
I am working on some project and have such situation:
I have Entity Service:
@Entity
public class Service implements Serializable {
@Id
private Long id;
@ManyToMany
Collection<Language> language;
}
And entity Language:
@Entity
public class Language implements Serializable {
@Id
@Column(length=4)
private String id;
}
Thanks to it I have Entity Service which contains collection of available languages in DB it creates table: Service, Language and Service_Language for many to many mapping.
Now I want to add subscription entity:
@Entity
public class Subscription implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
@ManyToOne(optional=false)
private Service service;
@ManyToOne
private User user;
@ManyToOne
private Language language;
}
Now it creates table Subscription with service_id field which is foreign key to Service.id and field language_id which is foreign key to Language.id
OK but in this situation I can create subscription entity with some service id and language which is not on that service list.
I need one more foreign key contraint: foreign key (service_id,language_id) references Service_Language(service_id,language_id)
Ive tried some methods but it does not work and I cannot find anything in Google.
Maybe some of you can help me.
Cheers
Mike
|
|
|
| Re: Addtional Foreign Kry [message #699955 is a reply to message #699813] |
Fri, 22 July 2011 11:58  |
| Eclipse User |
|
|
|
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 11:58 |
| Eclipse User |
|
|
|
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.02982 seconds
Home