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.
On 17/07/2014 1:32 PM, Jody Grassel
like to start a discussion on the issue reported by bug
#334899 as this is also an issue we're seeing with our own
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."
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.
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
To change your delivery options, retrieve your password, or unsubscribe from this list, visit