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

Updates documentation with valid string interpolation syntax #249

Merged
merged 1 commit into from
Jan 19, 2017

Conversation

naveedkakal
Copy link
Contributor

Bumped into this while copy pasting some code from the docs.

@brendon brendon merged commit 3cbc3b0 into brendon:master Jan 19, 2017
@brendon
Copy link
Owner

brendon commented Jan 19, 2017

Thanks @naveedkakal :)

@brendon
Copy link
Owner

brendon commented Jan 19, 2017

Wait a minute, if you use double quotes the interpolation will happen straight away. Normally we don't want this, we want the string to be interpolated in relation to the current record.

Can you double check this for me? Might have to revert this doc.

@naveedkakal
Copy link
Contributor Author

I think you may be right - let's revert it for now.

@naveedkakal
Copy link
Contributor Author

define_method :scope_condition do
  eval "%{#{scope}}"
 end

Looks like this is what I missed - i didn't realize it was an eval happening there.

Apologies!

@brendon
Copy link
Owner

brendon commented Jan 19, 2017

That's all good :)

@brendon
Copy link
Owner

brendon commented Jan 19, 2017

No worries man, it's a messed up configuration syntax anyway!

@naveedkakal
Copy link
Contributor Author

Interestingly the thing I was trying to solve for is actually an open issue with the PG::DEADLOCK issues.

For my case what I really needed to do is have some logic around the scoping attribute

acts_as_list scope: '#{plan_id ? "plan_id = \'" + plan_id + "\'": "1=0"}'

I was tinkering with a PR for acts_as_list to also accept a proc as a scope - do you think something like that would be a good idea? My reasons for it were related to another known issue so this may be just be a workaround that doesn't belong as supported functionality.

Any thoughts?

@brendon
Copy link
Owner

brendon commented Jan 20, 2017

Accepting a proc might be a good idea. Alternatively you can override the scope_condition and scope_changed? methods to do what you want. This is an example:

  def scope_condition
    ['notice_area_id = ? AND ? >= CURDATE()', notice_area_id, end_date]
  end

  # A custom acts_as_list scope requires a custom scoped_changed? method
  def scope_changed?
    changed.include?('notice_area_id') ||
    changed.include?('end_date') && (
      changes['end_date'][0] >= Time.zone.now.beginning_of_day &&
      changes['end_date'][1] < Time.zone.now.beginning_of_day ||
      changes['end_date'][1] >= Time.zone.now.beginning_of_day &&
      changes['end_date'][0] < Time.zone.now.beginning_of_day
    )
  end

I hope that helps :)

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

Successfully merging this pull request may close these issues.

2 participants