JPA 2.1 @ForeignKey

[El Deffo]

Hi, I'm having an issue with foreign keys, seems that 3.1.0-SNAPSHOT is still using Hibernate @ForeignKey which was deprecated after v4.3.0. I'm now getting lots of warnings and JPA validation errors (foreign keys missing in the table).

I think import org.hibernate.annotations.ForeignKey; should be changed to import javax.persistence.ForeignKey;

and annotations like 

@JoinColumn(name = "COUNTRY_ID", nullable = false)

@ForeignKey(name = "FK_CITY_COUNTRY_ID")

to JPA 2.1 compliant

@JoinColumn(name = "COUNTRY_ID", nullable = false, foreignKey=@ForeignKey(name="FK_CITY_COUNTRY_ID")).

[Torsten Juergeleit]

Good point. Thanks for spotting this.
Any chance to create a GitHub issue for this finding?

/Torsten

[El Deffo]

done, https://github.com/sculptor/sculptor/issues/168

[Torsten Juergeleit]

Hi, I'm having an issue with foreign keys, seems that 3.1.0-SNAPSHOT is still using Hibernate @ForeignKey which was deprecated after v4.3.0. 

Yes, the Hibernate annotation @ForeignKey is deprecated and will be removed in Hibernate 6. But using the JPA 2.1 annotation instead means dropping support for non-JPA2.1-compliant JPA providers (like OpenJPA) and deployment targets (like Google AppEngine).

I'm now getting lots of warnings and JPA validation errors (foreign keys missing in the table).

I haven't seen these warnings and errors in the test cases of Sculptors examples yet. Is there any chance to prepare a test case which shows these issues?

/Torsten

On Tuesday, February 10, 2015 at 10:53:58 AM UTC+1, El Deffo wrote:

[El Deffo]

I attached a sample spring boot+postgres project. I added "- List<@Moon> moons" to Planet entity, now

In Planet.java, 
@ForeignKey(name = "FK_MOON_PLANET_PLANET", inverseName = "FK_MOON_PLANET_MOON")

shows jpa validation errors: Foreign key "{0}" not found in the table "{1}".

I think the problem is that Hibernate's JPA 2.0 @ForeignKey doesn't create the FK in the database, probably some hibernate bug they don't see a point in fixing, as this annotation is deprecated already. After changing this to JPA 2.1 compliant @ForeignKey everything works as it should, the keys are created and found, but I would have to do it manually in all generated entities after each generate-sources.

Maybe there should be sculptor-generator.properties setting for JPA level? For now it would help greatly even if the only thing it did was to change the @ForeignKey template.
With JPA 2.2 coming soon and provider support that will surely lag behind, this branching is pretty much inevitable anyway.

[Torsten Juergeleit]

Are you really want to model a many-to-many association (with separate relation table) between Plant and Moon (this is the default if no keyword "inverse" or "opposite" is used for the reference as described here)? 

How about  using "- List<@Moon> moons inverse;" for a one-to-many association (with FK column defined via @JoinColumn) instead?

/Torsten

[El Deffo]

You're right, that would make more sense in this case, I didn't really think the example through.

Anyway, I took a better look, and the foreign keys are created correctly, I think this might just be a bug of Eclipse JPA validator.

So I guess this is not a big issue for now, I will probably just turn the validation off.
Thanks.

[Torsten Juergeleit]

Ah, you got those warnings and validation errors from the Eclipse Dali JPA validator =8-o

I was thinking you got them from the JPA provider (Hibernate) during runtime.

I'm glad this is fixed now.

/Torsten

[Ivica Loncar]

Also:

• Foreign key names: http://stackoverflow.com/questions/10197950/how-to-specify-fk-names-when-using-jointable-mapping
• https://hibernate.atlassian.net/browse/HHH-8862 Setting foreign key name on @CollectionTable has no effect
• https://hibernate.atlassian.net/browse/HHH-8783 @javax.persistence.Foreignkey#name does not change contraint na

ATM FK generation doesn't work as expected with JPA 2.1 style annotations

The best of it all: Hibernate guys closed issues mentioned above but there is no release with a fix :) I guess I will re-open it.

On Tuesday, February 17, 2015 at 10:27:41 PM UTC+1, El Deffo wrote: