0

I have a web app built on Ruby on Rails. In this app obviously use different Gems. Iv come to a point where i want to extend some specific gem's classes, and add methods to it.

Now i have a use case where i want to extend a gem's class, but instead of adding methods, i want to change its inherting class lets take the Impressionist Gem for example:

Iv created a new class in my app - app/models/impression.rb

class Impression < ActiveRecord::Base
  establish_connection(ENV[App_LOGS_DB'])
end

i want to change the Inheritance to use a my custom class called LogsBase

class Impression < LogsBase
end

the LogsBase class is definend as follows:

class LogsBase < ActiveRecord::Base
  establish_connection ENV['APP_LOGS_DB']
  self.abstract_class = true
end

When in try to run the server, the following exception is raised:

/gems/impressionist-1.6.1/lib/impressionist/models/active_record/impression.rb:5:in `<main>': superclass mismatch for class Impression (TypeError)

which from my understanding basically means there is a conflict between the gem's impression class definition and my own extention of that class.

Can anyone please help in finding out a way that i can change the Impression class inherting class, while still perserving the class's behaviour and making my server run properly?

PS: the goal of all this is to write the impressions data into a different database (logs db) rather than the main app db. in order to do that i need to establish a connection to the logs db, but if ill do it within the Impression class directly , it will blow up my pool of DB connections as indicated in the following link:

https://www.thegreatcodeadventure.com/managing-multiple-databases-in-a-single-rails-application/

thats why i need the abstract LogsBase class.

Any help will be appreciated.

zivaricha
  • 223
  • 4
  • 10
  • Consider making a PR to the gem, to allow the base class to be configured. (And then use your fork in the meantime.) – matthewd Aug 16 '18 at 11:48
  • It would be helpful to include a link to the library in question: https://github.com/charlotte-ruby/impressionist/blob/master/lib/impressionist/models/active_record/impression.rb – Tom Lord Aug 16 '18 at 13:25

2 Answers2

1

Disclaimer: do not do that!

The only way I can think of is a nasty hack, neither reliable, nor robust, that is not compatible with newer versions of your external gem. Since Ruby does not allow to redefine the classes ancestors, you might (but please don’t):

  1. grab the content of original /gems/impressionist-1.6.1/lib/impressionist/models/active_record/impression.rb file.
  2. copy-paste it into your /blah/foo/impression.
  3. make your class be loading impressionist/models/active_record/impression explicitly.
  4. in the very second line of the file unset original class.

Something like this:

require 'impressionist/models/active_record/impression'

Object.send :remove_const, 'Impression'

class Impression < LogsBase
  # ORIGINAL CONTENT OF THIS FILE
end
Aleksei Matiushkin
  • 119,336
  • 10
  • 100
  • 160
1

There is no (sensible) way to redefine a base class in ruby. It's possible, but only via weird hacks.

I would suggest taking one of two routes here:

  1. Fork the library, and make the base class configurable (with backwards compatibility).
  2. Don't do this via inheritance. Instead, put establish_connection ENV['SPLACER_LOGS_DB'] into a module, and include it in the class.

I would be inclined to use option 2 for now, as it's a quick/simple workaround that should fit well with the rest of the application.

Tom Lord
  • 27,404
  • 4
  • 50
  • 77
  • Regarding suggestion 2: Will calling the establish_connection method within a **module** and including it within my **model** will achieve the same goal of preventing reaching pool threshold as if i use **inheritance**? im not really sure it will... (or how can i test it for that matter) – zivaricha Aug 21 '18 at 14:03
  • @zivaricha If inheritance works, then module inclusion will work. If inheritance fails, then module inclusion will fail too. I'm not entirely sure how you could best test it either, but I can at least say the behaviour will be the same. – Tom Lord Aug 21 '18 at 14:12
  • @zivaricha to expand on this. Your concern about the pooling is unnecessary if `Impression` is the only class calling establish connection in this fashion. Do you have other classes that would inherit from `LogsBase`? – engineersmnky Aug 21 '18 at 19:17
  • @TomLord Gotcha, ill give it a try. engineersmnky, i have 8 other classes that establish a connection to a different DB same way the impression class suppose to. And all of these classes get hit very often, thats why I'm concerned. – zivaricha Aug 22 '18 at 07:18
  • @zivaricha If you have 8 other classes with this behaviour, then all the more reason to move it into a module anyway! :) – Tom Lord Aug 23 '18 at 17:31