@swanandp the CI error comes from bundle

Please install the sqlite3 adapter: gem install activerecord-sqlite3-adapter (sqlite3 is not part of the bundle. Add it to Gemfile.)

Shall I do something about that?

I think that calls for a separate PR. Go for it!

On Sat, Oct 3, 2015 at 11:05 AM, randoum [email protected] wrote:

@swanandp https://github.com/swanandp the CI error comes from bundle

Please install the sqlite3 adapter: gem install
activerecord-sqlite3-adapter (sqlite3 is not part of the bundle. Add it
to Gemfile.)

Shall I do something about that?

—
Reply to this email directly or view it on GitHub
#171 (comment)
.

Ok, noted. Let's focus on this one first if you don't mind. What's your feedback?

@swanandp any feedback? Thanks.

Sorry, got held up in other things, will come back to this shortly.

Ok sure.

@swanandp any feedback? Thanks.

@randoum tests have been fixed in master. Could you please rebase and fix hound issues as well?

Thanks.

I could really use this right now... 😞 I'm updating thousands of items in a list and it's wreaking havoc on my database.

Hi @nickpoorman, sorry to hear that. As a workaround you could use update_columns to circumvent all the callback logic. Or if you feel like chipping in on this PR please do :) It's at a bit of an impasse at the moment.

@wikyd, now that @swanandp has had his say, would you like to push this through along his recommendations?

I would like to help, but the proposed changes does not work with our use case. We have a Javascript front-end that allows users to re-order and remove items from the list. Then, we take this set of changes and update our items in a batch use Rails params -> model magic. Turning off callbacks for a specific model does not help in that case.

@wikyd, I've always found this to be the most troubling part of using acts_as_list. Unless you use the relative move methods or set one position at a time, the callbacks can get in the way. I often use this relation extension:

module Sortable
  def sort(array_of_ids)
    array_of_ids.each.with_index(1) do |id, index|
      where(:id => id).update_all(:position => index)
    end
  end
end

As a way to mass-assign positions passed in as a list of id's. It can be limited if the list of id's isn't all the id's in the scope though.

@wikyd - I'm actually doing the same thing. We have a bulk upsert endpoint that does a create/destroy/update all in one. For this route, I had to disable paper trail also, as it was creating massive amounts of rows in our versions table. They seemed to have solved this "disable" issue this way: https://github.com/airblade/paper_trail/blob/05dd9fb40848c2c8e7079eac7fccffb54720db9e/lib/paper_trail/record_trail.rb#L425

ie.

@widget.paper_trail.without_versioning do
  @widget.update_attributes :name => 'Ford'
end

...and it works quite well.

@nickpoorman, they're using some kind of class variable to track the disabled state? I'd assume that wasn't thread safe.

@brendon - I believe it is thread safe: paper-trail-gem/paper_trail#328

@brendon - I see what they did. They used https://github.com/steveklabnik/request_store to store the state. https://github.com/airblade/paper_trail/blob/8b9ce72f2c449becb3d75b094b9b07fb64b6e908/lib/paper_trail.rb#L62

@nickpoorman, ah yes, I use that in my applications too. It's handy, but may be brittle to add as a dependency in our case? Will there be any downsides say in the console?

I noticed ancestry has a similar method though I've not investigated how they do theirs.

@brendon, as far as I can tell request_store is a wrapper for Thread.current with some middleware to clean up after requests so I see no reason why it wouldn't work in the console.

Yes I suppose if the store variable is set and unset cleanly after the block executes then that would be fine.

Here's how ancestry is doing it: https://github.com/stefankroes/ancestry/blob/master/lib/ancestry/instance_methods.rb#L296

It's an instance method but is quite spread out in terms of its application in the code.

@swanandp, do you have any more thoughts given the latest comments here?

@brendon Definitely need to do the blocking on object level. Let's avoid class or thread level variables unless we have to, and we don't have to here.

Thanks @swanandp. @wikyd, @randoum given this direction, would one of you like to refactor this so that it uses an instance variable and also if possible includes just checks for this variable on the callback declarations rather than inline in the code?

Personally I have zero availability.
Just a note about request store. It is used in several gems for quite some times and seems to be maturely thread safe.

Thanks @randoum, that's all good. I have no doubts about the quality of RequestStore but as @swanandp says in this case, it's not necessary to use a thread level variable so I'd rather not add an unnecessary dependency. Thanks for your input on this PR to date. :)

I am not sure we can do without Thread.current.

If you can do @widget.paper_trail.without_versioning {@widget.update_attributes :name => 'Ford'} it's because the without_versioning statement concerns only @widget, which is a single record.

In our case an act_as_list_no_update block would apply to the behavior of multiple records or a whole model.

In terms of use case, you would never write:

TodoItem.find(5).acts_as_list_no_callback do
  update(:position => 5)
end

Because it's plain useless.

Instead, you would be using acts_as_list_no_callback for mass updates, mass ordering, mass import or such. Hence the statements would be concerning multiple records.

How can you write a block statement that concern multiple record? There's only one way, by using a block at the class level :

TodoItem.acts_as_list_no_callback do
  mass_import_method
end

2 choices: class instance variable or Thread.current variable. The second one is way safer.

So I understand you guys fears toward Thread.current, but I'd like to remind you that my original PR was based on http://api.rubyonrails.org/classes/ActiveRecord/NoTouching/ClassMethods.html which is part or rails core and using Thread.current.

If rails core team is using it, we can. We are using Thread.current in a block context, no around thread synchronization or between different webserver sessions, it's safe to use in our case. The only important thing is to clear the thread variable in an ensureblock.

Some reading : http://stackoverflow.com/questions/7896298/safety-of-thread-current-usage-in-rails

Hi @randoum, you make a good point :) @swanandp, can you chime in?

@randoum, your latest rebase has reverted a bunch of changes on master (Appraisal config, CHANGELOG etc...)

Yeah I messed up big time with git. I have no idea what I did. Finally I deleted my fork and I already started from a fresh one.

Kindly continue there #244

@wikyd @nickpoorman @StoneFrog if you guys don't mind to participate to #244. Thanks