On Tue, Aug 2, 2016 at 3:32 PM, <
jeffb.thom...@gmail.com> wrote:
> Couldn't that case be handled by using different cascade options on each of
> the relationships? So in your example, the user would not give A's list of
> magazines a CascadeType.REMOVE, and the ORM should respect that and not
> delete M2, even though the delete would cascade into A's sentences.
Yep, definitely can do that, and it's probably the preferred solution.
But, understanding how a delete propagates can get murky as the
modeling gets more sophisticated.
>
> I agree cascades can be tricky, but I think it's acceptable to leave it up
> to the user to configure them correctly so they don't misbehave.
>
> Also, when deleting an entity, wouldn't it be reasonable to delete all
> triples with that entity resource in either the subject or object position
> (or at least allow that as an option)? That seems like it would be easier
> to implement that validating that the deleted entity is not referenced
> outside the tp-be-deleted subgraph.
As an option, perhaps. But it's possible when deleting individual A,
triples with it as the object may be owned by something else, so I
dont think you could just always delete them safely.
I guess the tl;dr is, Empire errs on the side of caution, but could
stand some work to give the user some flexibility.
Cheers,
Mike