Hi,
When an application using O-R mapping has to resort to SQL, it often
signals some sort of limitation in domain model design and more importantly
using SQL takes away one of the most important benefits of O-R mapping
itself -- namely insulating your application from persistent database
schema.

The O-R mapping programming model prescribes that the application should
operate on the entity domain only, the O-R mapping vendor should translate
these operations to the persistent database schema both by structure as well
as by operation.

Coming to this specific problem, you have two operations at your disposal
for deletion. One in Java: Collection.remove(Object x) and other in JPA:
EntityManager.remove(Object x).
As a Link knows whether it is an association or composition, hence when Node
A delinks from Node B, Link(A,B) can determine whether to invoke
Collection.remove() (i.e. A.myNeighbours.remove(B)) for association or
EntityManager.remove() (i.e. em.remove(B)) for composition.

The persistence provider (OpenJPA or otherwise) should take over from
there and generate appropriate changes to database. If OpenJPA is not doing
that then please furnish further details.

What @ElementDependent does for OpenJPA is Collection.remove() becomes
EntityManager.remove() -- so Java association appears to be composition.

--
Sent from the OpenJPA Users mailing list archive at Nabble.com.