customink / secondbase

Seamless second database integration for Rails.
MIT License
220 stars 30 forks source link

Add a helper to force a connection to secondbase #4

Closed hmadison closed 9 years ago

hmadison commented 9 years ago

Lets you get around situations where you can't change the class inheritance but need to force the model to use secondbase.

cc @nhessler @ashirazi @AEgan @astupka

ashirazi commented 9 years ago

The name "ForceSecondbase" seems uncomfortable to me. Presumably, the usage would be something like:

class Foo < SecondBase::Base
  # my secondbase model
end
class Bar < MySqlModel
  # not a secondbase model, although I still want to use it?
  include ForceSecondbase
end

Even though I can see what will happen here, I am left confused as to the intent. Perhaps it's because we're mixing ActiveRecord and DataMapper paradigms.

hmadison commented 9 years ago

@ashirazi The useage ends up being

class Model < ActiveRecord::Base
extend Secondbase::ForceSecondbase
end

This gets around cases where a gem provides models and you can't edit the base class.

metaskills commented 9 years ago

@ashirazi See here. Specifically "Topic 5: Shared Connection/Pools". http://technology.customink.com/blog/2015/06/22/rails-multi-database-best-practices-roundup/

ashirazi commented 9 years ago

@metaskills yeah, I know what it's doing... I was asking why you would want to declare a model as backed by one DB (inheritance), and then have it use another (extension). Seems like this contradiction would lend itself to a different approach, e.g. different subclasses of AR::Base for each DB (each configured accordingly).

@hmadison If we authored the gem, then perhaps a configurable backing DB would be the better way of doing this. If we don't have control over the gem, then re-opening the models is one way to go.

metaskills commented 9 years ago

I know what it's doing... I was asking why you would want to declare a model as backed by one DB (inheritance), and then have it use another (extension).

The idea is that this is for models that you do not control, likely in other gems. In my article, I used the Delayed::Job ActiveRecord model as an example which is exactly what we need it for. Subclassing is the preferred way, but in cases like ActiveRecord's DB Sessions, Delayed::Job, you simply need to freedom patch.

nhessler commented 9 years ago

LGTM. I can see what @ashirazi is saying about the name of the module, but I can’t think of a better one. I’m on the fence but I’ll lean towards the current name.