Sequel: A Database Toolkit for Ruby [GitHub]
github.com
github.com
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.
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. :) )
However, the new AR in Rails 3 using Arel is pretty nice too; it's a massive improvement over AR 2. You might want to give it another look.
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.
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.
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.
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?
On what do you base this? While "NoSQL" storage suits some class of applications, where's the evidence that it suits all applications?