Cascade deletes

[Steve M]

When I delete an object cascade deletes don't seem to go more than one level deep.

For example I have an object "Magazine" which has a collection of "Article" which has a collection of "Sentence" All of these have cascade = {CascadeType.ALL}. When I delete a magazine the articles are deleted but the sentences still exist, Is this expected?



public class Magazine implements SupportsRdfId
{
    ...
    @OneToMany(fetch = FetchType.LAZY,
            cascade = {CascadeType.ALL})
    @RdfProperty("ufm:article")
    private Collection<Article> mArticles = new HashSet<>();
    ...
}

public class Article implements SupportsRdfId
{
    ...
    @OneToMany(fetch = FetchType.LAZY,
            cascade = {CascadeType.ALL})
    @RdfProperty("ufm:sentance")
    private Collection<Sentence> mSentences = new HashSet<>();
    ...
}

public class Sentence implements SupportsRdfId
{
    ...
    @RdfProperty("ufm:text")
    private String mText;
    ...
}

[Michael Grove]

On Mon, Aug 1, 2016 at 11:32 AM, Steve M <steven.m...@gmail.com> wrote:
> When I delete an object cascade deletes don't seem to go more than one level
> deep.

Right, that's a tricky problem. Say Magazine M has Article A, which
maintains a list of other magazines it was published in. If A was
republished in Magazine M2, if you cascade past the first level, you
may not want to delete M2.

Granted that's somewhat arbitrary, but, it's quite easy to delete
entirely too much information. Cascades would have to be made smart
enough to not delete anything that is referred to by something else
which is not being deleted. And even then, I'm not sure if that's
bulletproof.

Cheers,

Mike

> --
> You received this message because you are subscribed to the Google Groups
> "Empire" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to empire-rdf+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[jeffb.thom...@gmail.com]

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.

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.

- Jeff

[Michael Grove]

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