Implement ActiveRecord::Base.ignored_columns #21720
Conversation
|
cc @jeremy |
It actually wouldn't be hard to handle this. I think you'll just need to call |
|
Also just as a note, even though this is tangential to the feature, I'd like to have an explicit test that clarifies that |
Sure I can test this. |
|
Is this feature intended only for schema changing purposes, or would it make sense to use it for app logic in order to not expose to AR uneeded db columns for security, performance, or encapsulation reasons? In latter case, it's blacklist approach so I wonder whether it'll eventually grow into the same issue as |
|
A low priority feature I'm planning is the ability to turn off automatic On Tue, Sep 22, 2015 at 3:01 PM Eugene Gilburg notifications@github.com
|
|
@egilburg as mentioned in the PR description usages others than online schema change can be:
But yes online schema change is the biggest use case. |
|
We use pt-osc also. Adding and changing columns are generally safe, but dropping columns needs something like this. We rarely drop, partly because it's more problematic to pull off with no downtime. Declaring ignored attributes on the model is a pragmatic approach and a good proxy for reflecting the effective new schema change, but feels at a mismatched level of abstraction. Is there an alternate way to tell AR about the effective new schema? |
Not sure I understand what you mean here. You don't think the list of columns is an AR::Base concern? |
|
👍 Basically every large Rails app is already doing something like this. It'd be great to have an officially blessed way of doing it. |
byroot
force-pushed
the
ignore-columns
branch
from
db09af9
to
4ccdd41
Compare
Implement ActiveRecord::Base.ignored_columns
|
@byroot The behavior of the model and characteristics of its attributes are
Another approach would be to push the responsibility to Arel. Make the table's base relation a projection that doesn't include the defunct column. In either case, we're pushing up against a missing capability to control schema introspection ourselves. |
Follow-up to rails#21720.
| refute_includes Developer.columns_hash.keys, 'first_name' | ||
| end | ||
|
|
||
| test "ignored columns have no attirbute methods" do |
There was a problem hiding this comment.
Will fix. Thanks for the heads up.
Update the "Removing a column" section to include details on the `ActiveRecord::Base.ignored_columns` method that landed in rails/rails#21720.
|
Would there be any way to use this with single-table inheritance, to hide certain columns not relevant to a specific sub-class even though they are in the shared table? Or is the cached attribute list going to be shared, so you end up removing them from all or nothing anyway? |
`IgnorableColumn` module in `app/models/concerns/ignorable_column.rb` which is used in models to ignore dealing with specified columns. In Rails 5 with this [pull request](rails/rails#21720), `self.ignored_columns` was introduced to do this job. For example, in app/models/user.rb: ```ruby ignore_column :external_email ignore_column :email_provider ``` can be changed to: ```ruby self.ignored_columns = %i[external_email email_provider] ```
…ord 4.2 `ActiveRecord::Base.ignored_columns` was added in Rails 5 - rails/rails#21720
Use cases
This is useful when you use online schema change tools like https://github.com/soundcloud/lhm or pt-online-schema-change.
Since some columns will appear or disappear at any moment, you want to make those columns invisible to AR for a while. Otherwise you could have some processes knowing about the columns and others who don't.
Another use case could be to prevent the use of a column in one class that share a table via STI.
Unanswered questions
There is a couple edge cases I'd like thoughts on:
ignored_columnsafter the columns have been loaded. Should we allow it? If so it mean we need to undefine methods which not great. Maybe just a warning?@matthewd @sgrif @rafaelfranca for review please.