Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Regarding Bug #334899

Thanks for the input, this is exactly what I was looking for.  I suspected there was a reason for the difference in language between @Basic and the @ToOne relationships with respect to the optional attribute, this makes it more clear.

So in a nutshell, using it as a schema directive to set NOT NULL on the join column is out, otherwise it would interfere with shallow inserts.  That means that *-to-One optionality enforcement must be a runtime validation, and one that has the smarts to consider unloaded LAZY relationships, isn’t computationally expensive, etc.

On Jul 21, 2014, at 1:11 PM, Tom Ware <tom.ware@xxxxxxxxxx> wrote:

Hi Jody,

  Sorry for the slow response.

  I do not have any philosophical issue with address this, but please be aware of one gotcha.

  For relationships in a cycle (e.g. a -> b -> c -> a), on insert, EclipseLink will pick a place in the cycle and insert with the foreign key == null and immediately after the set of inserts is done update the null foreign key to point to the correct entity.  We call this a shallow insert (and googleing may yield some results showing alot of debate over that functionality).

  The reason for this functionality is to allow foreign key constraints to work.  i.e. Until c is inserted, I cannot set the foreign key in the b -> c mapping.   Any fix you will either have to allow shallow updates to work, or it will break backward compatibility.  Some databases allow deferral of constaints until commit, but not all of them, so assuming constraints can be deferred is not an option.

-Tom

On 17/07/2014 1:32 PM, Jody Grassel wrote:
I would like to start a discussion on the issue reported by bug #334899 as this is also an issue we're seeing with our own function tests.

The issue at hand is the optional attribute with the @ManyToOne and the @OneToOne relationships.  While the spec states that @Basic's optional attribute is both a hint and can be interpreted as a schema generation directive, the language used by the spec for the relationship annotations makes no such assertions.  It simply says "(Optional) Whether the association is optional. If set to false then a non-null relationship must always exist."

A simple test demonstrates that there is no runtime validation during flush/commit and the schema generation does not specify NOT NULL for the join column.

I intend to pursue a solution to this problem, but wanted to hear some feedback from the community on what the preferred solution would be: runtime validation or schema generation?


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


Back to the top