
Sequel: A Database Toolkit for Ruby [GitHub] - emson
http://github.com/trafficbroker/sequel
======
aphyr
I've used sequel and activerecord extensively--most recently at
<http://vodpod.com>, which has, er, non-trivial database requirements.

Hands down, Sequel is the superior library. Arbitrary many-through-many-
through-many-... relationships, totally customizable callbacks for association
building/caching, trivially easy master/slave and multi-master sharding,
infinitely chainable and extensible subsets, powerful grouping and joining
support... the list goes on and on. Plus it's bloody _fast_. let's put it this
way: it is almost _never_ necessary to drop to raw SQL with Sequel. The only
cases in which I've done so have been implemented as Sequel features or
plugins within three months. In ActiveRecord, we have to drop to SQL all the
time.

Plus, the code is _clean_. Extremely modular, readily extensible; anyone who's
poked around in the AR source can tell you what a nightmare it is to figure
out what's going on.

Also, Jeremy Evans (the author), and the rest of the community around it, are
awesome--check out #sequel on Freenode sometime.

~~~
jamesbritt
I started with AR for Jotbot (my desktop JRuby app), but it had assorted
funkiness that made using outside of a gem environment too annoying, so I gave
up. (Gem code should not have 'require "rubygems"' littered about. )

I had been using Sequel with Web apps already, and when I needed to add
adapter code for the Java H2 DB it was pretty straightforward, plus Jeremy was
quite helpful.

Besides, Sequel always felt more like Ruby than AR.

Big props to Jeremy and team for a sweet library.

(Just wish it had a different name. :) )

~~~
tibbon
The name is ever so slightly problematic. Google still often thinks that
Sequel is mySQL or SQL.

~~~
bk
Search for _ruby +sequel <your-keywords>_

------
jpcx01
Official version is here: <http://github.com/jeremyevans/sequel>

Lots of good docs here: <http://sequel.rubyforge.org/>

For anything SQL, Sequel is to me the best of breed library. Blows
ActiveRecord away at anything.

I used to like DataMapper when I'm building apps from scratch. But since then
I've replaced that with MongoMapper to target MongoDB.

Sequel is still always going to be in my tool box as its great for working
with any existing SQL database.

~~~
andrewbrown
yeah that fork is way behind with the original, follow this baby.

<http://github.com/jeremyevans/sequel>

------
tibbon
I've been using Sequel quite a bit with Sinatra and just Ruby by itself in
scripts. The documentation could be a little better (isn't that always true)
to keep up with the rapid development, but overall its rather amazing.

I wish there was a good page on the main site about why/how it is different
than ActiveRecord. My other friends are always wondering, "Why do you want to
use that instead of AR?" and I can't honestly give them a perfectly clear
answer. Mainly because it works well for me.

The absolute best part is that Jeremy Evans is amazing in IRC at helping out
anyone with issues. I've pasted him huge sections of code that he's helped me
out with before. He never treats me like a n00b, or flames someone for asking
a question that they themselves may have even asked before. He's really a nice
guy and a strong model for how a primary project maintainer/lead can help
bring others in.

------
simonw
Why is this a link to a fork rather than the original?

~~~
melvinram
Original: <http://github.com/jeremyevans/sequel>

------
mjw
Another Sequel user here, very happy.

The only thing I'd like to see would be a more flexible object mapping layer
on top of the relational core. Something along the lines of Python's
SQLAlchemy.

Sequel::Model is a simple ActiveRecord-style ORM layer (in the sense of
Fowler's ActiveRecord pattern) and in a way is very flexible, if you don't
mind implementing a bunch of lower-level hooks for certain things.

But sometimes you do want a more heavyweight session-based approach where you
have an object model with a bunch of associations, a flexibly-configured
mapping of that object model to the database, and an ORM which knows how to
take a batch of changes to the object graph and commit them to the database in
one transaction.

Still yet to see a tool like this for ruby, but I think sequel could be a good
foundation for it.

------
LucaB
I would like to find some good support for sequel in rails3, as it's happening
with datamapper: datamapper's crew seems to be very "active" in the domain of
"marketing", taking the rails3 occasion to low (near to zero) the barriers to
jump on the boat... is there anything like that for sequel? I would like to
try, and that would be a great encouragement... Thanks a lot!

------
davidalln
Thanks for posting this. I was trying to get through ActiveRecord and
DataMapper on non-Rails/Merb/Sinatra ruby programs when I arbitrarily went to
HackerNews and saw this: a much simpler solution to what I needed (without
using straight up SQL which I find is frustrating to work with and debug).

------
j_baker
So is "database toolkit" the trendy way to say "object-relational mapper"
these days?

I guess what I'm getting at is why should I as a random HN reader care about
Sequel as opposed to other ORMs like Hibernate, nHibernate, SQLAlchemy, Storm,
Subsonic, or any other ORM in any language? What makes it neat?

------
larrywright
I've used both Sequel and Active Record. I like Active Record when working
with a brand new Rails-ish database, but for working with anything else,
Sequel is great. It's much more of a general purpose database library than AR
is, which makes it perfect for non-greenfield work.

------
andrewbrown
I'm liking the syntax but I don't think it has all the goodies that
ActiveRecord offers. Though all this SQL stuff doesn't really matter because
the future of web-apps are all going to be driven by non-relational databases
such as MongoDB. I really do like the Sequel effort,the code is clean.

~~~
jamesbritt
"Though all this SQL stuff doesn't really matter because the future of web-
apps are all going to be driven by non-relational databases such as MongoDB"

On what do you base this? While "NoSQL" storage suits some class of
applications, where's the evidence that it suits _all_ applications?

