Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating an item with a nil scope should not add it to the list #92

Closed
matteomelani opened this issue Sep 18, 2013 · 11 comments
Closed

Comments

@matteomelani
Copy link

Thank for this great gem.
I have a quesiton/issue related to default scope. Thanks for any help.

class NewContent < ActiveRecord::Base
  acts_as_list add_new_at: :top, scope: :collection
end

n = NewContent.create
puts n.position 
   => 1

But collection_id is null.

This is creates a huge performance problem because every time I create a NewContent it is going to add to the list of item with collection_id set to null.

@matteomelani
Copy link
Author

Overwriting the scope_condition seems to work

def scope_condition
    if collection_id.present?
      "collection_id = #{collection_id}"
    else
      "id = -1"
    end
 end

@swanandp
Copy link
Contributor

Hi @matteomelani ,

acts_as_list does not maintain the value for scope, it'll only look up the scope while re-ordering, inserting etc.

The correct way would be:

n = NewContent.new(collection: collection_id)
n.save

@randallb
Copy link

@swanandp I think you're misunderstanding the issue.

If I don't want to add an item to a collection, I definitely don't want to set the position column, so that I don't incur the performance penalty of looking up the entire list of nil items.

Right now I'm trying to hack around this when I discovered this issue.

http://stackoverflow.com/questions/22334899/conditionally-activate-acts-on-list-when-field-is-defined

@johnnyiller
Copy link

I just ran into this problem... Huge performance issue when you are first creating items then optionally adding them to a list later on... I guess the solution is to add them to some sort of temp list or something, but that seems a bit silly. Really there should be a way to only update the list if the scope variables are set...

@thefron
Copy link

thefron commented Apr 22, 2015

I'm facing this issue too.
I need something like complete disable of ordering when scope id is nil.

@brendon
Copy link
Owner

brendon commented Apr 17, 2016

This doesn't sound like a bad idea. Would one of you like to take a stab at implementing it and creating a PR?

Right now I guess nil is as valid a scope as say 1 or whatever your custom scope is, so acts_as_list is using that to group your items. We're assuming you order all your things.

If I hear nothing after a few weeks I'll close this until someone is happy to work on it.

@brendon
Copy link
Owner

brendon commented Jun 2, 2016

Closing due to inactivity. @thefron, @johnnyiller, @randallb, @matteomelani feel free to contribute a PR to solve this issue.

@brendon brendon closed this as completed Jun 2, 2016
@mathportillo
Copy link

sorry for commenting on a closed issue,
but should this be easier to achieve now that there is acts_as_list_no_update ?

@brendon
Copy link
Owner

brendon commented Mar 8, 2018

Yes, that's definitely the case, but that'd be implemented on your end. If you want to look at a solution regarding a scope that evaluates to nil then certainly have a go :)

@phikes
Copy link

phikes commented Jan 21, 2021

Recently stumbled upon this as well. The API of the method is now slightly different, it seems. This works for us as of today:

  def scope_condition
    if list_id.present?
      { list_id: list_id }
    else
      { id: -1 }
    end
  end

@smlparry
Copy link

smlparry commented Jun 8, 2021

@phikes solution works for me, but yeah, this should probably be part of the library

Was having an issue where all records with a nil scope were getting their updated_at being updated :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants