In our specific project we have an object called CommunicationSetting that defines an automated email that a client is setting up. That setting has many different child objects, Filters for example, which would exclude or include people from the recipient list. In this example we would like the client to be able to test how changes to their filters will affect the recipient list. So we would like to take their proposed changes (which might include additions, modification, and deletions), modify the objects in memory, get the list and return it to the UI so the user can review it. If the user likes the changes, they can hit save to persist the object to the database, or if they don’t like it the can abandon their changes and leave the objects in the database as it.
If deletions could be deferred until save time, than running these types of experiments become very trivial. The transaction workaround is plausible, but the whole point of having ActiveRecord objects in memory is the ability to modify them without persisting. Right now the behavior is inconsistent. Additions and modification to objects in a relation are performed in memory only, while deletions are immediately persisted to the database. I think that the inconsistency in behavior is the biggest problem. If I had something like this: c = CommunicationSetting.find(1) the_filters = c.filters # => [#<Filter:0x007f9abe7c3408>, #<Filter:0x007f9abe7b2b30>] Then I changed the_filters modifying one, removing one, and adding a new one, then executed c.filters = the_filters The modification and addition would be in memory only, while the deletion is persisted to the database immediately. This seems very inconsistent and counter intuitive. On Wednesday, February 17, 2016 at 2:04:32 PM UTC-7, Nicholas Firth-McCoy wrote: Could you run your code within a transaction and call the existing > `destroy` method, and then rollback the transaction in the case that you > don't want the deletion to persist? > > Can you share some real world examples showing why you'd need to be able > to soft delete the associated records? There might be other, better > workarounds. > > My guess is that this would be a complicated feature to add, but I'm not > too familiar with the parts of ActiveRecord that this would touch. > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
