ActiveRecord::Relation#settings is prone to conflicts
adamcrown opened this issue · comments
#settings
is a pretty generic name to have at an Active Record model level. Specifically, I know it at least conflicts with elasticsearch-model.
I'm be happy to create a pull request to change this to something like #clickhouse_settings
, but I know that would be a breaking change that would involve a new major version, I'd assume. So I wanted to get some feedback on the willingness to make that change first.
Can you explain what the conflict is?
Sorry for the late reply. I got pulled off on another urgent issue for a while, but I'm back to focusing on this now.
So here's how I'm seeing it in the project I'm currently working on.
Gemfile
gem 'elasticsearch-model'
app/models/user.rb
class User < ApplicationRecord
include Elasticsearch::Model
end
Before adding the clickhouse-activerecord
gem
User.method(:settings).source_location
=> ["/src/vendor/bundle/ruby/3.1.0/gems/elasticsearch-model-6.0.0/lib/elasticsearch/model.rb", 118]
After adding the clickhouse-activerecord
gem
User.method(:settings).source_location
=> ["/src/vendor/bundle/ruby/3.1.0/gems/clickhouse-activerecord-0.6.2/lib/active_record/connection_adapters/clickhouse_adapter.rb", 66]
So you see that both gems are attempting to define a .settings
method at the ActiveRecord model level and one winds up overriding the other.
Thanks for your help with this!
This is inevitable when using different gems in the same model. You need to reconsider the usage model for ClickHouse and for ElasticSearch.
Example:
class UserEs < ApplicationRecord
include Elasticsearch::Model
end
class UserCl < ApplicationRecord
establish_connection :clickhouse
end
Okay. Not a problem, as Elasticsearch does have a namespaced version that can be used via #__elasticsearch__
. But in my opinion, it would be prudent to better namespace the methods to something like #clickhouse_settings
or similar to avoid these sort of conflicts.