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

Behavior with DB default seems unclear #219

Closed
maxim opened this issue Aug 13, 2016 · 4 comments
Closed

Behavior with DB default seems unclear #219

maxim opened this issue Aug 13, 2016 · 4 comments

Comments

@maxim
Copy link

maxim commented Aug 13, 2016

Thank you very much for maintaining this gem. Have a use case that could maybe use a little love (I know it's been discussed before, but not enough it seems).

We have acts_as_list declared like this:

acts_as_list scope: [:active]

In DB position default is set to 1, but the problem is: each new record still goes to the bottom. Setting position to 1 explicitly, or using position_will_change! doesn't help (probably because it's equal to what's already set by default). A note in the README says this is normal, and refers to "recent discussions", however, that note was written in 2011, and I couldn't find any discussion that helps work around this, would appreciate some help.

I did also try adding add_new_at: :top, but with that the problem is that it always goes to the top, even when a position is provided.

I managed to hack together this workaround, the downside being that I have to use this method instead of standard AR create, and it has to do the creation in 2 DB interactions.

  class << self
    def create_at_position(params, &block)
      transaction do
        item = create(params, &block)
        item.move_to_top unless params[:position]
      end
    end
  end

Wonder if there is better way to do this that I could at least help document.

@brendon
Copy link
Owner

brendon commented Aug 14, 2016

Hi @maxim :) Thanks for bring this up. I've created a PR with a test that confirms the bug: #220

If you come up with any insight as to how to work around this problem, please let me know :)

@brendon
Copy link
Owner

brendon commented Aug 14, 2016

Updated the PR with a fix though it actually changes tested behaviour so I'm not quite sure wether to merge it or not.

@brendon
Copy link
Owner

brendon commented Aug 23, 2016

Closed by #220.

@brendon brendon closed this as completed Aug 23, 2016
@brendon
Copy link
Owner

brendon commented Aug 23, 2016

0.8.0 has been released and includes this change.

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

2 participants