Any thoughts on this proposal?
On Thursday, February 18, 2016 at 11:26:18 AM UTC-8, Jeremy Mickelson wrote:
>
> I agree complete that `delete` and `destroy` should remove objects from
> the database immediately. The situation that I'm talking about is not
> really related to the deletion of individual objects, its about how
> associations behave.
>
> If I have a model with a has many, and I alter the array that represents
> that association, it's not clear that some of those changes are in memory
> and some are immediately persisted to the database. I would expect the
> parent model to keep internal state representing either the objects to
> delete on save or a copy of the original array so it can diff at save time
> and detect the changes.
>
> For example:
>
> ``` ruby
> f = Filter.first
> f.destroy # happens immediately
>
> c = CommuncationSetting.first
> the_filters = c.filters # contains 3 items
> new_filters = the_filters.select { |f| /* only keep 2 of them */ }
> c.filters = new_filters # right now active record deletes the remove
> filter immediately
> c.save! # I propose that it should wait to delete the removed filter until
> here
> ```
>
>
> On Thursday, February 18, 2016 at 12:16:08 PM UTC-7, Geoff Harcourt wrote:
>>
>> One way you could handle this would be to add a virtual attribute to your
>> model with `attr_accessor` called `marked_for_deletion`. You could then use
>> that flag as a temporary change to your model without deleting it, and then
>> delete those objects in the final DB transaction after the user approves
>> the proposed changes. An advantage of this approach is that if your user
>> abandons their approval that none of your changes have been persisted to
>> the database (the virtual attribute is lost as soon as the model is no
>> longer being referenced).
>>
>> Another approach you could use would be the “soft delete”, where deleted
>> models aren’t removed from the database, but are rather marked with a flag
>> or a deleted_at timestamp. If you adopted that strategy, you would avoid
>> having the records disappear from your database, and you could unwind the
>> action fairly easily.
>>
>> In a non-soft delete scenario, I think calling `#delete` or `#destroy` on
>> a model and not having it be deleted immediately would be unexpected
>> behavior.
>>
>> On February 18, 2016 at 2:01:55 PM, Jeremy Mickelson (
>> jeremy.m...@gmail.com) wrote:
>>
>> 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 rubyonrails-co...@googlegroups.com.
>> To post to this group, send email to rubyonra...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
--
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 rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
