5 ms·

Ambition - AR Adapter to write db queries in Ruby

11 points by kunley 16y ago

epochwolf 16y ago
Looks similar to the work going on with Rails 3. http://github.com/rails/arel http://github.com/rails/arel
- dkubb 16y ago
  This works predates Rails 3 by about 2 or 3 years. I would bet it indirectly influenced AR3, and I know it has influenced DataMapper (which I maintain). One major difference with Ambition is that you're writing the queries in the same code you would when using the normal Enumerable API. IMHO from an interface pov, it's better than any Ruby ORM has provided (or would ever be able to). However, the (big) downside is that it requires ParseTree, which only works on Ruby 1.8. It's also a bit fragile, since if you use code the underlying parser doesn't understand you'll get weird runtime errors. I created an Ambition-like interface to DataMapper early last year, which uses a similar approach: http://github.com/dkubb/dm-ambition/ The main difference (aside from working with DataMapper) is that when the underlying collection is already lazy loaded the block provided is evaluated for each record using the normal Enumerable methods. I believe the Ambition project has a few constructs that make this impossible, but in dm-ambition I set this as a requirement from the start.
  - kunley 16y ago
    Very interesting. Thanks for the explanation. My hacker colleague who lives on the edge with DataMapper says Ambition-like stuff is to be included in DM. Is that related to your gem or a completely different activity?
  - grandalf 16y ago
    For anyone who isn't already using DM, you should be. Thanks Dan!
adamtj 16y ago
It seems to me to be a pointless, hacky kludge. As with every other ORM, the abstraction will leak as soon as you do anything interesting. Even if it doesn't leak, there is mental stress involved with convincing yourself that it won't. And then you still have the performance problems. How does this make life easier? What am I missing? Is this just for people who need to do "SELECT * FROM comments WHERE articleid=?" and don't want to learn even that much SQL?
- kunley 16y ago
  Well if you put is this way, all is lost: you've already decided it WILL leak. Without checking. What are you missing? It's not that user wouldn't know SQL. It's that code like this is more readable because you don't do a mental switch in your brain. I'm all for it: see my story [1] for a take on readability. Or just accept the fact that there are tools around for mature people who enjoy it. DHH didn't create his ORM for dumb people, he did it because it made his hackin' universe more pleasurable. Some dumb people used it later, but who cares. [1] http://inthephase.org/back-to-ruby http://inthephase.org/back-to-ruby
  - adamtj 16y ago
    As I see it, its easier to mix any subset of procedural, oop, or functional code than it is to mix either of those with relational queries. Operating on query results WITH Ruby is easy. Writing relational queries AS ruby is a big impedance mismatch. There isn't a simple mapping I can hold in my head. Here there be magic, in the form of implicit joins. Also, good luck trying to optimize. It's not that I've decided it will leak, it's that I can never quite trust that it won't. I would have to continually prove to myself that my code is right. It's a weakness of mine that if I don't 100% understand the code I'm writing, I worry and that slows me down. That code becomes something I can't quite get out of the back of my mind. Also, I don't buy your readability argument. I can read and think in SQL just fine. Yes, SQL can be complicated, but only when the problem requires it. It maps very directly and naturally on to the problem of querying. There isn't much in SQL that isn't necessary. There isn't much in SQL that is missing. It's already as simple as can be. To make it any simpler makes it worse. Mixing the asking of a question with the processing of the answer makes both parts harder to understand. Perhaps it is easier to read for some people, but I think that's likely because they just aren't very good with SQL yet. So, this seems to me to make code less readable and more difficult to reason about. I don't see the advantage.
datapimp 16y ago
This is pretty much exactly what Thoughtbot's Squirrel does. They decided to discontinue work on Squirrel though.
donw 16y ago
If you're in Ruby and you want a battle-hardned ORM for SQL with a great query-builer, use Sequel: http://sequel.rubyforge.org/ http://sequel.rubyforge.org/ Or, if you're in Rails 3, just use Arel, which is part of ActiveRecord.

11 points by kunley 16y ago

epochwolf 16y ago

Looks similar to the work going on with Rails 3. http://github.com/rails/arel http://github.com/rails/arel

dkubb 16y ago
This works predates Rails 3 by about 2 or 3 years. I would bet it indirectly influenced AR3, and I know it has influenced DataMapper (which I maintain). One major difference with Ambition is that you're writing the queries in the same code you would when using the normal Enumerable API. IMHO from an interface pov, it's better than any Ruby ORM has provided (or would ever be able to). However, the (big) downside is that it requires ParseTree, which only works on Ruby 1.8. It's also a bit fragile, since if you use code the underlying parser doesn't understand you'll get weird runtime errors. I created an Ambition-like interface to DataMapper early last year, which uses a similar approach: http://github.com/dkubb/dm-ambition/ The main difference (aside from working with DataMapper) is that when the underlying collection is already lazy loaded the block provided is evaluated for each record using the normal Enumerable methods. I believe the Ambition project has a few constructs that make this impossible, but in dm-ambition I set this as a requirement from the start.
- kunley 16y ago
  Very interesting. Thanks for the explanation. My hacker colleague who lives on the edge with DataMapper says Ambition-like stuff is to be included in DM. Is that related to your gem or a completely different activity?
- grandalf 16y ago
  For anyone who isn't already using DM, you should be. Thanks Dan!

adamtj 16y ago

It seems to me to be a pointless, hacky kludge. As with every other ORM, the abstraction will leak as soon as you do anything interesting. Even if it doesn't leak, there is mental stress involved with convincing yourself that it won't. And then you still have the performance problems. How does this make life easier? What am I missing? Is this just for people who need to do "SELECT * FROM comments WHERE articleid=?" and don't want to learn even that much SQL?

kunley 16y ago
Well if you put is this way, all is lost: you've already decided it WILL leak. Without checking. What are you missing? It's not that user wouldn't know SQL. It's that code like this is more readable because you don't do a mental switch in your brain. I'm all for it: see my story [1] for a take on readability. Or just accept the fact that there are tools around for mature people who enjoy it. DHH didn't create his ORM for dumb people, he did it because it made his hackin' universe more pleasurable. Some dumb people used it later, but who cares. [1] http://inthephase.org/back-to-ruby http://inthephase.org/back-to-ruby
- adamtj 16y ago
  As I see it, its easier to mix any subset of procedural, oop, or functional code than it is to mix either of those with relational queries. Operating on query results WITH Ruby is easy. Writing relational queries AS ruby is a big impedance mismatch. There isn't a simple mapping I can hold in my head. Here there be magic, in the form of implicit joins. Also, good luck trying to optimize. It's not that I've decided it will leak, it's that I can never quite trust that it won't. I would have to continually prove to myself that my code is right. It's a weakness of mine that if I don't 100% understand the code I'm writing, I worry and that slows me down. That code becomes something I can't quite get out of the back of my mind. Also, I don't buy your readability argument. I can read and think in SQL just fine. Yes, SQL can be complicated, but only when the problem requires it. It maps very directly and naturally on to the problem of querying. There isn't much in SQL that isn't necessary. There isn't much in SQL that is missing. It's already as simple as can be. To make it any simpler makes it worse. Mixing the asking of a question with the processing of the answer makes both parts harder to understand. Perhaps it is easier to read for some people, but I think that's likely because they just aren't very good with SQL yet. So, this seems to me to make code less readable and more difficult to reason about. I don't see the advantage.

datapimp 16y ago

This is pretty much exactly what Thoughtbot's Squirrel does. They decided to discontinue work on Squirrel though.

donw 16y ago

If you're in Ruby and you want a battle-hardned ORM for SQL with a great query-builer, use Sequel: http://sequel.rubyforge.org/ http://sequel.rubyforge.org/ Or, if you're in Rails 3, just use Arel, which is part of ActiveRecord.