Paving path for being able to reuse ActiveRecord's connection

[Janko Marohnić]

Hi Jeremy,

I've tried to gather some thoughts on Twitter regarding the idea of using Rodauth in a Rails app, and some people who looked at the rodauth-rails README expressed concern with Sequel requiring a separate database connection. I'm not too happy about it either, as currently in rodauth-rails the Sequel connection needs to play catch with ActiveRecord in order for things to work in different contexts.

I know the ability to reuse ActiveRecord's connection has been talked about before, but I wanted to talk about possible changes to Sequel that could me made to allow this. My idea was ship an "activerecord" adapter within rodauth-rails (or extract it into a gem), whose `Database#connect` would retrieve a raw connection object from ActiveRecord, and do any adapter-specific modifications needed that other Database#connect methods do, while for Postgres wrapping it in a `Sequel::Postgres::Adapter` class.

To make this work, I thought we could make Sequel::Postgres::Adapter delegate to the underlying PG::Connection object instead of a subclass, which would allow initializing it with ActiveRecord's PG::Connection object. I've made a raw proof-of-concept, which uses ruby's DelegateClass to avoid using #method_missing to hopefully minimize the performance impact. If I ran the tests correctly, they seem to pass both without and with sequel_pg.

Now, this implementation should still be improved. For one, it should probably use class_eval instead of define_method for performance (so it probably shouldn't use DelegateClass, as that uses define_method). And it still needs to address postgres-pr compatibility.

But, putting these things aside, do you think this approach could work?

Kind regards,

Janko

[Jeremy Evans]

I'm not going to consider changes to the Sequel postgres adapter simply for compatibility with ActiveRecord. I think the approach you need to take is:

* Use a custom connection pool class that checks out connections from the ActiveRecord connection pool (most important change).

* Use a custom adapter if the current Sequel adapter won't work due to connection object differences.

You may not need the custom adapter if you can modify the ActiveRecord connection to conform to the API Sequel expects.

You should also consider the opposite approach, having ActiveRecord checkout connections from Sequel's connection pool.  However, I can see how people would have more resistance to doing that if they are using ActiveRecord primarily and Sequel only incidentally.

Thanks,

Jeremy

[Janko Marohnić]

Hi Jeremy,

Thank you for your reply. Thanks to it I've managed to come up with a sequel-activerecord-adapter gem that uses an approach similar to what you've described. No Sequel changes were needed after all, and it was much easier that way too.

I think this will help reduce the gap between ActiveRecord and Sequel, allowing people to transition to Sequel or use a library that uses Sequel without any performance impact.

Kind regards,

Janko