Postby phillipuniverse » Tue Nov 13, 2012 12:54 am
This is also implemented on the ProductImpl class itself in the @SqlDelete annotation.
The reason that we went with this solution is really 2-part. I believe the initial motivation was to deal with the changeset feature that was implemented so that we could have versioned modifications to the catalog. This allows admin users to do a soft-delete but can always recover later.
The other part to this is because of what you touched on a bit in your post there about it being "a little messy" to delete those products. Because of foreign key constraints that we have on our domain you can't really hard-delete anything without running into constraint violations. This becomes a real problem when a user has already purchased that Product and it's related to an OrderItem. Generally speaking you never want to physically delete your Order domain so the right answer here isn't to just cascade the delete around to the rest of your database.
It's possible in the future that we will modify this behavior but we think this is the correct solution for the majority of cases. You could technically implement your own hard deletion cleanup cron job if you would like, but again you will have to take into account the foreign key constraints.
The Broadleaf forums are being retired as a readonly archive of questions. For active discussions and questions, check out the
broadleaf-commerce tag on Stack Overflow which is actively monitored by the Broadleaf team.