> I like DataMapper, but I can't say I care for the conditions syntax.
> Yes, the use of operators is kind-of cool, but the #lt, #gt, etc
> methods and the extension of Symbol with #desc and #asc are pretty
> blech. And am I missing something, or is there the potential for name
> clashes for properties named :order, :limit, etc?
There is the potential if you have a property name :limit or
something, but in those cases you can always wrap the conditions
inside a :conditions hash, eg:
User.all(:conditions => { :limit => 1 }, :limit => 10)
When run against an RDBMS this will generate something like this:
SELECT <cols> FROM "users" WHERE "limit" = 1 LIMIT 10
Although in general I would recommend not naming properties the same
as built-in matchers.
> Some time ago Peter VanBroekhoven did a cool video on a SQL like DSL.
> I can't find the video anymore, but to give you an idea, you could do
> things like:
>
> Song.select do |s|
> s.artist =~ /Mary/ & s.year > '1980'
> end
>
> It's sort of a cross between working with an Enumerable and working
> with SQL, but in pure Ruby and without having to extend core classes.
> I would really like to see something like this for DataMapper in the
> future.
I think you're referring to Ambition, which was written a few years
ago and works with ActiveRecord. I wrote a version with an improved
API for DataMapper last year:
http://github.com/dkubb/dm-ambition
Check out the examples in the README, they are pretty awesome.
Like Ambition this uses ParseTree to parse the Proc at runtime.
However, while Ambition translates the parsed code almost directly
into an SQL String, DataMapper creates an abstract Query object. The
benefit of this approach is that the Query can be handed to any
adapter and executed. This means it's not just a front-end to a few
RDBMS', it works with the ~40 or so backends that DataMapper supports.
It's beautiful to work with -- I actually wish this had caught on
more, because it is IMHO the nicest query API for any ruby ORM, but I
can understand why it didn't.
First of all, it only works with Ruby 1.8, and not 1.9 or JRuby.
ParseTree won't work on 1.9 because there is no longer a way to access
the AST at runtime. I think there's a ParseTree for JRuby, but I don't
think it's maintained. I'd bet that you could port this to Rubinius.
At MWRC I was talking to a Maglev developer, and he said that you can
access the AST at runtime, so there's the potential of it being ported
to there too. So I guess the only hold-out is Ruby 1.9, which is a
really big deal since it's the reference implementation, and outlines
the direction everything is heading.
As far as I know there is no work-around to this, and nothing planned
by the ruby core team, but if you know of something please let me
know.
--
Dan
(dkubb)
--
You received this message because you are subscribed to the Google Groups
"DataMapper" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/datamapper?hl=en.
