doctrine-extensions / DoctrineExtensions

Doctrine2 behavioral extensions, Translatable, Sluggable, Tree-NestedSet, Timestampable, Loggable, Sortable

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support for on-delete='CASCADE' with soft deletes

mbadolato opened this issue · comments

When using soft deletes, and entity object is not actually being deleted, thus no cascades trigger down to associated objects.

My original email with @l3pp4rd and @comfortablynumb:

I'm using the soft delete feature, and its working well. In the relationship defined below, I have soft delete set up on both the Event entity (where this association is defined), as well as the associated entity, EventMetaDataValue.

I'd like to include on-delete="CASCADE" so that the associated EventMetadataValue's deletedAt timestamp also gets updated, however this doesn't seem to trigger. Presumably this is because I'm not actually deleting the Event entity, since I'm using soft delete.

My question is, is there a way to have that behavior take place (i.e., cascade the soft-delete down to the associated table)? Scouring the net didn't lead me to anything useful, and your docs don't reference a situation like that. I was hoping there was a syntactical way to carry out this operation, and that I won't have to write a listener to take care of it.

    <entity name="Cms\CoreBundle\Entity\Event" table="event">
         ...
        <many-to-many field="eventMetadataValues" target-entity="EventMetadataValue">
            <join-table name="event_metadata">
                <join-columns>
                    <join-column name="event_id" referenced-column-name="id" />
                </join-columns>
                <inverse-join-columns>
                    <join-column name="event_metadata_value_id" referenced-column-name="id" />
                </inverse-join-columns>
            </join-table>
        </many-to-many>
         ...
    </entity>

And Gustavo's response:

You're right, since entities which are not explicitly removed from the entity manager don't trigger any events, they are not handled by softdeleteable. One way would be to use cascade delete. But, of course, this avoids the perfomance boost of using normal db cascade delete.

We could detect, however, an entity which is being deleted and, if it has a configuration in its join columns with cascade delete, we could softdelete its children.

+1 for this feature, the actual implementation creates exceptions with the JMSSerializer which throws "Entity was not found" exception when trying to load an entity by ID but since it has added the WHERE deletetAt == null it doesn't return anything and gives errors.

@comfortablynumb Were you ever able to determine if this would be possible, and if so, how difficult of an implementation?

Is there something new on soft delete and cascade remove?

it may not be hard to implement, but the author of softdeleteable is away.. and there is no news about it, most probably someone will contribute to solve this

I came across this same problem but the other way around:
I have a Sale entity that has a price, a date and a service id.
And I have a service entity that have an id and a name.

I want to be able to delete the service as expected but the sale still appearing in the history, and referencing that same service. Any suggestion on this?

👍

subscribe the event 'preSoftDelete'

This would be a great improvement!

Any update or work-around on this?

+1

commented

@Puty Please use reactions now, instead of +1 comments.

@RubenHarms GitHub needs a "weeps for joy" reaction icon. Thank you!

@adapik @gustavodpont @funcphp @glnemeth @ghanbari @versh23 @gpenverne

I've removed your comments. Please use reactions instead of +1 comments.

Hi,

Has any progress been made during the years regarding this missing feature? Is it still an issue in v3?

No progress that I'm aware of.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Has this issue been solved? The completed tag seems misleading, perhaps it should be reopened?