Please use the google group to ask questions - thanks.

>>
In our case, a Child cannot exist without its parent. So if we remove a Child from the collection, we do want it to be deleted.
<<

Assuming it's a OneToMany and not a ManyToMany. Then removing a child element from a list/set will not invoke a delete. That is, Ebean does not listen for additions/deletions from OneToMany's (but it does for ManyToMany in order to maintain the intersection table).

In Ebean you would just remove it from the list/set and delete it yourself via Ebean.delete(removedChild);

Does that make sense?
Does that answer your question?

Cheers, Rob.

So Ebean does not support that for one-to-many releations. I found it quite convenient in Hibernate that e.g. if I have an Order I can remove a Line Item from it and then just save the order to have the item removed from the DB. In EMF (Eclipse Modeling Framework) they use the term containment for such releations, i.e. for object graphs where one object (child) is contained by another one (parent) removing the child from the parent and persisting the object graph will remove the child from the underlying data storage.

EclipseLink introduced a custom annotation called @PrivateOwned that does this as well. In OpenJPA it is @ElementDependent.

Any chance to have such a behaviour implemented in a future release of Ebean?

Yes, I think it could be quite useful so yes I think we can certainly look to add this feature.

I'm not 100% clear on the behaviour though so if you want to define/clarify the behaviour that would be great. Specifically in relation to the standard JPA cascade=CascadeType.ALL etc.

My thoughts is that you typically would want to use it with a CascadeType.ALL.

@OneToMany(cascade=CascadeType.ALL)
@DeleteOrphan
List details;

... and what this means is that any element removed from the list is going to be deleted when you save the bean.

If this is the correct/desired behaviour... then technically I think Ebean would only need to listen for removals (it doesn't need to listen for additions as they are saved via the existing CascadeType.ALL behaviour.

I assume that a clear() ... would have the effect of deleting all the elements in the list? What if the list has not been loaded yet?

Anyway, if that sounds about right ... I don't that would be too hard to implement. Just need to split the "modify listening" behaviour into "modify listen additions" and "modify listen removals"... as we only need to listen and register the removals.

How does that sound?

Cheers, Rob.

sounds good!

I think @DeleteOrphans would usually be used with CascadeType.ALL
But of course it might also be used without another cascade action, e.g. in conjunction with REMOVE: when the parent is removed, remove all items in the association. Additionally, when an item is removed from the association remove the item too.

Regarding the name I think best practice for annotations is to use a passive, describing wording, therefore I'd prefer @PrivateOwned over @DeleteOrphans

When clear() is called and the list has not yet been loaded I would still expect that all formerly referenced objects get removed from the database.

Logged as Enhancement: http://www.avaje.org/bugdetail-168.html

Nice.

This is actually the only issue that prevents me from switching to ebean. I am eagerly waiting for the resolution :-)

Fixed in HEAD.