Hi Grosser!

Good work on the gem and thanks! I have been using flag_shi_tzu for sometime now, but the development has been neglected. I would love to fork your project and add some features and some simplicity, but I don't want to waste my time submitting a pull request that will never get accepted. I need your buy-in and direction on some design changes before I get started in order to increase the chances of getting my pull request pulled. :)

I would like to add sequential keys in the bitfield options. IMO, it would be easier to maintain a list of flags/bits if the number used for the key was NOT the value of the bit but the number. The values get large quick, with the value getting to 4096 on the 12th bit and 4294967296 on the 32nd. I would like to add some bit shifting to make this more simple. Can I add this support? I wanted your permission before I changed the API since existing users of the gem would have to update their code. Thoughts?

Cheers!

I'd like for something like this to work: Document.joins(:user).where(users: { admin: true }).

This is probably quite difficult to achieve, since it's converted back to an SQL query by Arel under the hood. It's also worth noting that Arel isn't a stable interface, so it'll probably have some maintenance overhead. Not surprised if this doesn't get addressed, but is there a recommended way to phrase queries like this?

I'd like to have a function that can take in a hash of the bitfields and return the integer that would be made.

Hi @grosser,

Your gem looks really nice and the code is really easy to read. I wanted to use this gem for a project I'm working on and came across a situation where the default values for all bits would be true. I'd like to have a bit-field about email notification preferences and by default, all options should be true.

So, I was thinking how do I achieve this? How can I have the individual bits default to true? Should I set the default value of that column to INT_MAX? Then I thought, wouldn't it be nice to have an additional option in your gem called e.g. defaults_to where you can specify true to get the desired behavior. Of course, this defaults_to option would be purely optional and would only make sense when set to true:

bitfield :notification_options,
  1 => :notify_of_new_follower,
  2 => :notify_of_new_post,
  3 => :notify_of_new_comment,
  defaults_to => true

What do you think? Would you say this would be a nice addition or wouldn't that make much sense from your point of view? I would gladly write the code for that and send you a pull request.

Cheers,
Philipe

I will keep looking of course, but for some reason, while running integration tests, the bitfield is not available:

*** NoMethodError Exception: undefined methodflags' for #WorkItem:0x007ff697151a40`

It works fine in the normal course of events (e.g., rails server, rails console).

In readme is stated

[Defaults] afaik it is not possible to have some bits true by default (without monkeypatching AR/see tests) -> choose a good naming like xxx_on / xxx_off to use the default 'false'

But I just had this

bitfield :reminders_bits,
         2 ** 0  => :notify_one,
         2 ** 1  => :notify_two,
         2 ** 2  => :notify_three

And I want :notify_two and :notify_three to be true by default, so I just run this migration and everything is working as expected

DEFAULT_REMINDER_BITS = [1, 2].inject(0) { |v, k| v | 2 ** k }
change_column_default :model, :reminders_bits, DEFAULT_REMINDER_BITS

Is there any drawback in doing this?

Is it possible that something may break in gem functionalities because of this?

I'm trying combine Bitfields with Rails 4.2 and have a problem.
In 4.2 changed_attributes works different way and there is a problem in line 183:

if defined? changed_attributes
  send(:changed_attributes).merge!(bit_name.to_s => old_value)
end

I tried fix it by using attributes_changed_by_setter alias (check lukasztackowiak/bitfields@1bda52396121cb48f31d4bc36cfaaac2ecc441e5) but this caused more issues deeper in Rails. I can try dig deeper and maybe fix that but I'm not sure if that piece of code is really needed. I don't see any place where Bitfields relay on changed_attributes and for Rails I think it doesn't matter - it still keep information about changes in bitfield column.
Can you take a look and let me know if I should hunt for more complex solution or simply can remove this part from Bitfields code?

When using the should have_a_bitfield matcher, I received this error.

Here's the code:

require 'spec_helper'
require 'bitfields/rspec'

describe List do
  it 'has its bitfields' do
      should have_a_bitfield :featured # throws error
  end
end

I'm using:

• bitfields 0.7.0
• Ruby 1.9.3
• Rails 3.2.22
• rspec 2.14.1

Any help would be greatly appreciated!

Right now my current experience with the gem for json serialization behavior is:

class MyModel < ActiveRecord::Base
    include Bitfields
    bitfield :blah, :blah1, :blah2, :blah3
end

m = MyModel.new(:blah1 => true, :blah2 => true, :blah3 => false)
m.to_json

will yield

{"blah":3}

Is there any way to get it to produce the bitfields in the serialized output?

Thanks!

Hi! Thanks for the handy gem.

I'm using bitfield in my User class as follows:

class User < ActiveRecord::Base
  ...
  bitfield :email_preferences, 1 => :credits_email, 2 => :weekly_results_email, 4 => :challenges_email, 8 => :jackpot_results_email
  ...
  before_create :set_email_prefs_to_defaults
  ...
  def set_email_prefs_to_defaults
    if !attribute_present?(:email_preferences)
      self.credits_email = true
      self.weekly_results_email = true
      self.challenges_email = true
      self.jackpot_results_email = true
    end
  end
end

Unfortunately, this spec is failing:

  describe "set_email_prefs_to_defaults" do
    it "should not set the email preferences to the defaults on create if they're already set" do
      user = Factory(:user, :credits_email => false, :weekly_results_email => false,
                            :challenges_email => false, :jackpot_results_email => false)
      user.credits_email.should == false
      user.weekly_results_email.should == false
      user.challenges_email.should == false
      user.jackpot_results_email.should == false
    end
  end

I believe this is due to this behavior:

User.new(:credits_email => false, :weekly_results_email => false, :challenges_email => false, :jackpot_results_email => false).attribute_present?(:email_preferences)  #=> false
User.new(:credits_email => false, :weekly_results_email => false, :challenges_email => false, :jackpot_results_email => false).email_preferences  #=> nil

It seems as though the bitfield is not being set when all bits are set to false. Unless I'm mistaken, this does not seem to be desired behavior. I'm using version 0.4.0. Any thoughts/help would be appreciated. Thanks!

I think this is similar to the issue #21:

Assume the following code:

extern crate bitfield;
use bitfield::bitfield;

pub const SIZE: usize = 33;

bitfield! {
    pub struct Foo(MSB0[u8]);
    impl Debug;

    pub u8, foo, _ : 0;
}

fn main() {
    let buffer = [0u8; SIZE];
    Foo(buffer).foo();
}

This will result in:

error[E0599]: no method named `foo` found for struct `Foo<[u8; 33]>` in the current scope
  --> src/main.rs:16:17
   |
7  | / bitfield! {
8  | |     pub struct Foo(MSB0[u8]);
9  | |     impl Debug;
10 | |
11 | |     pub u8, foo, _ : 0;
12 | | }
   | |_- method `foo` not found for this
...
16 |       Foo(buffer).foo();
   |                   ^^^ method not found in `Foo<[u8; 33]>`
   |
   = note: the method `foo` exists but the following trait bounds were not satisfied:
           `[u8; 33]: std::convert::AsRef<[u8]>`
           `[u8; 33]: std::convert::AsMut<[u8]>`

If you lower the size to "32" (or less), it works.

Example:

UserAreaAccess.bitfield_sql(:open => @filters[:access_types][:open], :close => @filters[:access_types][:close], :emergency => @filters[:access_types][:emergency])

These params are ANDed together, but I need an option to OR them. So if anyone of them is TRUE a record will be returned.

ActiveRecord 5.1 deprecated many methods in the Dirty API and they will be going away in ActiveRecord 5.2

The bitfields gem still depends on many of the old methods such as send("#{column}_was").

In addition, the API that bitfields are emulating is the old deprecated API. It's probably a good idea to update this match the new Dirty API.

I'll give this a shot and try to pull together a PR.

I'm calling bitfield without specifying the index of each field:
bitfield :preferences, :prefA, :prefB, :prefC
And when I set them all to true, it shows up in the database with the value "14" => 1110. It seems like in the gem you never use bit0:
args.each_with_index{|field,i| options[2**(i+1)] = field } # add fields given in normal args to options
Since you're doing (i+1), the first index you get in the bitfield is 1 (with a mask of 2**1, you're setting bit1 first). You should be able to retrace this just by using the setup above and setting them all to true, you'll get the value 14 in the preferences column instead of the expected 7.

It's possible to set up multiple columns and retrieve bits, but it's impossible to set the values on specific columns with same bitfields

  bitfield :exposed_fields, 2**0 => :title,
                            2**1 => :last_name,
                            2**2 => :first_name,
                            2**3 => :address_1,
                            2**4 => :address_2,
                            2**5 => :postal_code,
                            2**6 => :city

  bitfield :required_fields, 2**0 => :title,
                             2**1 => :last_name,
                             2**2 => :first_name,
                             2**3 => :address_1,
                             2**4 => :address_2,
                             2**5 => :postal_code,
                             2**6 => :city

I tried to use this with includes similar to how I had in #44, but the query didn't return any results. It might be possible to query from the other direction and map, but I find that sub-optimal. Is there a way to use includes with this?