Allow initializing enummer with hash #22
Conversation
GabrielNagy
force-pushed
the
values-with-indexes
branch
from
b16deea to
32a9eca
Compare
|
Hi and thanks for the PRs! I'll definitely give them a look as soon as I have a spare moment! |
|
Hey hey! Would you mind looking at the conflicts, @GabrielNagy? |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #22 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 4 4
Lines 70 71 +1
Branches 8 9 +1
=========================================
+ Hits 70 71 +1 ☔ View full report in Codecov by Sentry. |
Similar to the Rails `enum` behavior, allow initializing an `enummer` with a hash where the values correspond to the indices of the bits that map to the flag. This is a more robust and backwards-compatible approach to enums, as the developer doesn't have to worry about migrating historical data if an enum value is removed.
GabrielNagy
force-pushed
the
values-with-indexes
branch
from
32a9eca to
007a36f
Compare
All done, thanks! |
Support for using strings as setters was added in 441cdf6, but the initial implementation suffers from an idempotency issue, as changes would be committed to the DB even if the values were the same. Consider the following scenario: u = User.last => #<User:0x00007c747d137810 id: 3, permissions: [:read, :write], facial_features: [], diets: [], transport: [], home: []> u.permissions = u.permissions.map(&:to_s) => ["read", "write"] u.changes => {"permissions"=>[[:read, :write], ["read", "write"]]} Because we cast the values to symbols when serializing, we set the correct bitmask but this comes with the drawback of altering the DB even if the new values are the same. A better way to handle this issue is to delegate the responsibility to the `cast` method. If we do this we can drop the initial fix, as values will _always_ be symbols. It's tricky to test something like this, so I've opted to hook into ActiveRecord notifications and confirm no SQL UPDATE is being triggered if the values are the same.
|
I've pushed an additional commit to fix another issue I ran into while using enummer. It's completely unrelated to the functionality introduced by the PR at hand but I added it here to avoid conflicts and such. Let me know if you want me to open a separate PR for it @shkm. Thanks! |
|
Cheers! Thanks for cutting a new release too 🎉 |
Similar to the Rails
enumbehavior, allow initializing anenummerwith a hash where the values correspond to the indices of the bits that map to the flag.This is a more robust and backwards-compatible approach to enums, as the developer doesn't have to worry about migrating historical data if an enum value is removed.
I also took the liberty of running
standardrbon the entire project, seeing as the gem is part of the development dependencies.Thanks again for this useful gem!