Hi Jeremy, Thank you for your reply. Thanks to it I've managed to come up with a sequel-activerecord-adapter <https://github.com/janko/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 On Friday, April 24, 2020 at 4:56:31 PM UTC+2, Jeremy Evans wrote: > > 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/59c02824-5ca4-42cc-ba8f-d318b4060132%40googlegroups.com.
