What is it?
Why should you use it?
- No migrations needed for new boolean attributes
- Avoids ALTER TABLE when adding a new boolean field to a model, which can be important for very large tables
- Only the one integer column needs to be indexed
- The index is actually meaningful, unlike a boolean column index
- Bitwise operations are fast, indexes are even faster, and you can use either one
- Adds scopes to easily access collections of records with specific fields
- Chained scopes to combine sql for different bit fields for maximum performance
- Provides condition builder methods for each bit field so you can construct your own custom SQL with the correct bit field values for the list.
- Table alias option to allow it to work with tables aliased in a query (e.g. custom joins)
- Has a
set_flag_sqlmethod useful when doing mass updates without initializing object for each row.
- Has a
update_flag!method useful when you want to set a flag, but avoid validations and callbacks on the record.
Why is it better than the alternative?
The competition is Michael Grosser’s bitfields, and as always, it depends on your needs. Grosser’s library is less than half the size of
flag_shih_tzu, and has far fewer features, and a much smaller compatibility matrix. Some of the differences are laid out below.
For some things however, you only have one option. If you are still on legacy Ruby or legacy Rails, or using jRuby, then use
flag_shih_tzu. If you need multiple flag columns on a single model, use
flag_shih_tzu. If you want to use it with form builders, it is slightly easier with
|Age||Mar 2009||Mar 2010|
|Legacy MRI Support||1.8.7, 1.9.2||None|
|Current MRI Support||1.9.3, 2.0, 2.1, 2.2||1.9.3 2.0|
|Current jRuby Support||jRuby-1.7, jRuby-9.0||None|
|Legacy Rails Support||2.3, 3.0, 3.1, 3.2||None|
|Current Rails Support||2.3, 3.0, 3.1, 3.2, 4.0, 4.1, 4.2||3.2, 4.0, 4.1, 4.2|
|Custom Flag Column Name||Yes||Yes|
|Multiple Flag Columns per Model||Yes||No|
|Has analog to
|Built-in use with
|Built-in use with form builders||Yes||No|