Topic: acts_as_list problematic behavior on destroy
I'm trying to do a before_destroy test with a model that uses acts_as_list, only to discover that I cannot test the position value of my object in before_destroy. Upon exploring the plugin, it appears that it's because of the plugin's before_destroy call, which sets the position to nil and decrements all other positions in its scope.
Am I the only one that sees this as a problem? If a destroy fails, database integrity is lost, as is any hope of restoring data to the way it was before. To make matters worse, try to delete two. Suddenly, you have a piece of a valid list, and two nil-valued position rows which cannot be sorted unless forcibly assigned to a new position.
It strikes me that restricting delete behavior should be controlled in the model, and not checked in every possible destroy call location. Granted, that can be done as well, but it suddenly causes database behavior and preservation to become a controller issue, instead of a model issue. MVC, anyone? Accurate control of this in the model appears to be impossible right now.
I'm primarily coming here for agreement or an explanation of why my understanding is flawed (which it very well may be), and hopefully a way to get around this behavior. Also, can anyone help me verify that changing this to an after_destroy call won't throw a massive wrench in the works? And is there anyone out there who uses / relies on this remove_from_list before before_destroy behavior? If there isn't, and making it an after_destroy call won't break things, I'll look into submitting it to the project.