janklan
commented
2 months ago I'm a random bypasser, but here are my thoughts: The "restore" feature would have to be aware of how far should it restore things - not only the deleted entity, but how about, say, records in related weak entities supporting ManyToMany associations? Other cascaded deletions? ...
I think this alone makes it a feature that can't work out of the box, without an explicit configuration. Also the association graph might be massive, unless all entities in scope know how to serialize themselves ("which properties should be in scope of this feature").
Overall, it feels like a can-of-worms feature that will be bigger and more clunky than it seems. Is it the right answer to your problem?
Perhaps you can get away with a second schema shadowing the main one, with no FK or unique constraints, and have a trigger to every table that would copy the removed record over to this second schema. That way you'd always have all data kept in an archive. If you add a timestamp column to each record, you can also have a regular process in place removing things older than X to make sure the archive schema doesn't just grow forever.
Alternatively @Huluti is playing with a tool that will help you map all the cascades, so if your entity was removed because of misconfiguration of your associations, maybe the right solution is simply having it configured right - which isn't easy! Check it out, maybe it will help: https://github.com/Huluti/DoctrineRelationsAnalyser
I'm guessing this is probably not possible, but we happened to have deleted by error some entities (fk relation cascade). So we thought maybe we could restore them from the audits, is there an easy way to do it ?
Would this be an interesting feature for the bundle to add ?