On Friday, April 24, 2020 at 2:34:53 AM UTC-7, Janko Marohnić wrote: > > 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 > <https://github.com/janko/rodauth-rails/blob/master/lib/rodauth/rails/active_record_extension.rb> > > 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 > <https://github.com/janko/sequel/commit/c23ccd25d1076cdea4045e9503f6654e26c2b759>, > > 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? > 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 -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/f367b26a-bcda-4a55-831d-c13f04093107%40googlegroups.com.
