{"id":830,"date":"2010-01-05T16:56:21","date_gmt":"2010-01-05T16:56:21","guid":{"rendered":"http:\/\/salientsoft.co.uk\/?p=830"},"modified":"2011-11-17T13:03:58","modified_gmt":"2011-11-17T13:03:58","slug":"manytomany-issues-with-eclipselink-1-1-2","status":"publish","type":"post","link":"https:\/\/salientsoft.co.uk\/?p=830","title":{"rendered":"@ManyToMany issues with Eclipselink 1.1.2"},"content":{"rendered":"<p>I found\u00a0a number of issues when configuring a many to many relationship, but eventually found a working solution.<\/p>\n<p>1\/\u00a0 This example for a many to many uses <strong>referencedColumnName<\/strong> when it does not need to &#8211; it was a\u00a0hangover from an example using multiple join columns. If you do this with Eclipselink 1.1.2 and Oracle (in my case XE\u00a010g), the columns are created with data types of varchar2(255) instead of the default\u00a0of number(19) \u00a0:-<\/p>\n<pre>\u00a0\u00a0\u00a0\u00a0\u00a0 @ManyToMany\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 @JoinTable(name=\"AppUserRole\",\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0joinColumns =@JoinColumn(name=\"AppUserID\",\r\n                                          referencedColumnName=\"AppUserID\"),\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0inverseJoinColumns=@JoinColumn(name=\"AppRoleID\",\r\n                                          referencedColumnName=\"AppRoleID\u201d))<\/pre>\n<p>The referencedColumnName attribute is the cause of this issue. Leaving it out causes correct column types. It is only needed for multiple column joins (which break anyway see 2\/), and so should not be used. This therefore works correctly and is the recommended format to use \u00a0:-<\/p>\n<pre>\u00a0\u00a0\u00a0\u00a0\u00a0 @ManyToMany\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 @JoinTable(name=\"AppUserRole\",\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0joinColumns =@JoinColumn(name=\"AppUserID\"),\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0inverseJoinColumns=@JoinColumn(name=\"AppRoleID\"))<\/pre>\n<p>2\/ Using a many to many as in 1\/ but with multiple join columns causes<strong><a title=\"https:\/\/bugs.eclipse.org\/bugs\/show_bug.cgi?id=300485\" href=\"https:\/\/bugs.eclipse.org\/bugs\/show_bug.cgi?id=300485\"> eclipselink bug 300485<\/a>.<\/strong> (Although listed as a one to many bug it also happens with many to many). This is not due to be fixed until eclipselink 2.1. The bug gives a query parameter not found error for an internally generated query used when eclipselink lazily loads a relationship collection.<\/p>\n<p>3\/ Leaving out the <strong>@JoinTable<\/strong> and only having the\u00a0<strong>@ManyToMany<\/strong> annotation\u00a0works ok, but gives an XML column name resolution error from eclipse for one of the join columns. This is purely an \u2018invalid validation\u2019 however, as the code runs fine against a database created from it.<\/p>\n<p>4\/ using the xml annotations in <strong>orm.xml<\/strong> along with just an <strong>@ManyToMany<\/strong> annotation in the code works fine, but you do get some validation errors from Eclipse as the validation does not appear to merge the annotations and xml correctly when validating\u00a0:-<\/p>\n<pre>&lt;entity&gt;\r\n\u00a0\u00a0&lt;attributes&gt;\r\n\u00a0\u00a0\u00a0&lt;many-to-many name=\"appRoles\"&gt;\r\n\u00a0\u00a0\u00a0\u00a0&lt;join-table name=\"AppUserRole\"&gt;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0&lt;join-column name=\"AppUserID\" column-definition=\"number(19)\"\/&gt;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0&lt;inverse-join-column name=\"AppRoleID\" column-definition=\"number(19)\"\/&gt;\r\n\u00a0\u00a0\u00a0\u00a0&lt;\/join-table&gt;\r\n\u00a0\u00a0\u00a0&lt;\/many-to-many&gt;\r\n\u00a0\u00a0&lt;\/attributes&gt;\r\n\u00a0&lt;\/entity&gt;<\/pre>\n<p>This would be the preferred route if anything database specific\u00a0 was needed,\u00a0such as the <strong>column-definition <\/strong>attributes for Oracle in the example.\u00a0 The \u201c@ManyToMany\u201d annotation on the entity may be superfluous in this case but is a helpful label. A comment in the code that there are overrides in orm.xml would be helpful. The above fragment was tested but without the <strong>column-definition<\/strong> attributes on the columns &#8211; these are shown as examples of how to add database specific column definitions without having to pollute the code with them via annotations.<\/p>\n<p>The intention here would be to use xml in conjunction with annotations, with annotations used for all the standard metadata. Different versions of <strong>orm.xml<\/strong> and <strong>persistence.xml <\/strong>could then be swapped in and out for different back end databases, keeping the code standard. The same approach has been advocated to permit using Oracle sequences <strong><a title=\"http:\/\/salientsoft.co.uk\/?p=209\" href=\"http:\/\/salientsoft.co.uk\/?p=209\">here<\/a>.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>I found\u00a0a number of issues when configuring a many to many relationship, but eventually found a working solution. 1\/\u00a0 This example for a many to many uses referencedColumnName when it does not need to &#8211; it was a\u00a0hangover from an example using multiple join columns. If you do this with Eclipselink 1.1.2 and Oracle (in [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[8],"tags":[13,35,182,29,16],"_links":{"self":[{"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/830"}],"collection":[{"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=830"}],"version-history":[{"count":8,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/830\/revisions"}],"predecessor-version":[{"id":1573,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/830\/revisions\/1573"}],"wp:attachment":[{"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=830"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=830"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=830"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}