Looks really interesting, but I'll never touch it (unless forced to) due to Crudcast's dependence on MongoDB. Having already had MongoDB corrupt itself multiple times (testing the integrity of my backups), I want nothing to do with it for anything I have to support for external customers.
Its one thing to lose a few hours of data to MongoDB corruption on an internal service where the data can be mostly recreated without impacting or requiring anything from users & customers, but exposing users to that risk is unacceptable IMO.
Thanks for the feedback. I'd eventually like to add support for other DB types, but these would probably still be document-oriented due to the complexity of managing a SQL database through something like this
Sounds like you are restoring a backup into your live database instead of restoring it into a fresh instance where you can be assured of the state of the database. It’s best practice where a database instance costs you practically nothing.
3 comments
[ 2.6 ms ] story [ 22.2 ms ] threadIts one thing to lose a few hours of data to MongoDB corruption on an internal service where the data can be mostly recreated without impacting or requiring anything from users & customers, but exposing users to that risk is unacceptable IMO.