sequel-activerecord_connection VS Sequel

For the integration to work, I would need to make Sequel reuse Active Record's database connection. I discussed this idea with Jeremy Evans (the lead Sequel maintainer), and he provided me with some guidance, thanks to which I was able to come up a solution. It was a Sequel extension that retrieved Active Record connections, kept transaction state and callbacks synchronized between Sequel and Active Record, integrated SQL instrumentation, and reconciliated adapter differences (see my previous article for more details).

Our Rails app at work is using Active Record, but I started non-apologetically using Sequel for any features I'm missing from Active Record, because I don't have the patience for Active Record to catch up. For our analytics database we're using only Sequel, because AR was missing too many features (see my article), while for our main database we're using it in tandem with Active Record, reusing Active Record's database connection. I'm pretty happy that the latter is now possible, as it gives people the opportunity to try out Sequel without any overhead.

The way I look at it, a pure Active Record implementation could never be fully complete. That's why I instead chose the path of making Sequel integrate seamlessly with Active Record, by sharing a database connection as /u/honeyryderchuck said, hooking into Active Record's query instrumentation, and also by making Sequel transactions interoperable with Active Record's. It's also worth noting that core Sequel is significantly lighter than Active Record.

the main impediments to my using sequel in Rails are: authentication - which has largely been solved. Janko has written a gem allowing for rod auth to be used with rails, easily. https://github.com/janko/rodauth-rails - i believe he has also written another gem to make it easy to use sequel in a rails app https://github.com/janko/sequel-activerecord_connection

From a user's perspective, I've always found the fact that rom-sql uses Sequel under-the-hood as a big advantage. For someone who is familiar with Sequel it lowers the barrier of understanding how rom-sql works. And it's possible to leverage many of Sequel's useful features that rom-sql might not support OOTB (including performance optimizations such as sequel_pg), even if that requires dropping to the Sequel database level. When I announced sequel-activerecord_connection, one of the questions I received was whether that will work with rom-sql too (and it does).

Some of the most enlightening books I’ve read when I was first learning Ruby were Text Processing in Ruby, and Building Awesome Command Line Apps in Ruby 2. They each reveal certain features and perspectives that work towards this end, such as text parsing moves, Ruby flags to help you build shell 1-liners you can pipe against, and features with stdio beyond just printing to stdout.

Then add in something like Pry or Irb, where you are able to build castles in your sandbox.

Most of my data exploration happens in Pry.

A final book I’ll toss out is Data Science at the Command Line, in particular the first 40 or so pages. They highlight the amount of tooling that exists that’s just python shell scripts posing as bins. (Ruby of course has every bit of the same potential.) I had always been aware of this, but I found the way it was presented to be very inspirational, and largely transformed how I work with data.

A good practical example I use regularly is: I have a project set up that keeps connection strings for ten or so SQL Server DBs that I regularly interact with. I have constants defined to expedite connections. The [Sequel library](https://sequel.jeremyevans.net/) is absolutely delightful to use. I have a `bin/console` file that sets up a pry session hooking up the default environment and tools I like to work with. Now it’s very easy to find tables with certain names, schemas, containing certain data, certain sprocs, mass update definitions across our entire system.

```

Thea answer to your prayers already exists: http://sequel.jeremyevans.net/.

By far the best database toolkit (ORM, query builder, migration engine) I have seen for any programming language.

Ruby sequel (http://sequel.jeremyevans.net/) is the only library where you can combine classic ORM Model bases usage, with a more raw query builder "just get me all the data into plain objects". You'll never need anything again in your career life.

If you want a db tool which can be an ORM for your app, and drop down to a lower level dsl, while targeting specific features of the databases it supports, + having a "composable superset for building queries", there's [ruby sequel](http://sequel.jeremyevans.net/), which is the best tool of the kind you'll get for any proglang. Everything the author wants, minus the typrchecking perhaps, which is IMO shooting at the stars.

I love the Sequel library from Jeremy Evans (so much better than Rails' AREL). I've used it as my ORM-of-choice since 2008. When leveraging Sequel I almost always use the DSL, but there are times that I want to use bare SQL. When that happens, I almost always use HEREDOCs and my own version of String#squish.