Timeline for Pattern for syncing databases with undo option
Current License: CC BY-SA 4.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 24, 2020 at 19:37 | comment | added | JimmyJames | @JohannesHahn The point here is that the way you solve this kind of problem is fundamentally about how you structure the data. That is, you need to keep track of all the transformations. If you were starting from scratch, I would suggest a insert-only database design although that doesn't necessarily address changes made by multiple users. In that model, you would simply delete the changes or mark them as soft deletes. | |
| Nov 24, 2020 at 17:34 | comment | added | Johannes Hahn | Maybe I'm missing something, but the memento pattern does not seem viable in my situation or really any situation with lots of different changeable business objects. Writing memento-related classes and methods for each entity would simply be an unmaintainable nightmare of boilerplate code. And that code would also need to replicate some JPA-features like handling of @ Embeddable, @ IdClass, @ EmbeddedId etc. The only hope of ever improving the mess that is our legacy code is some generic solution that builds on top of JPA. | |
| Nov 24, 2020 at 16:31 | history | answered | JimmyJames | CC BY-SA 4.0 |