On Mar 18, 4:47 pm, "Dan Kubb (dkubb)" <[email protected]> wrote: > > 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.
Very cool. This is exactly the kind of syntax I'm talking about. But, yes, using AST is problematic. Looking it over, about 90% of this can be done in pure Ruby using meta-programming techniques. I wouldn't mind working on it, but I'll need to understand a little more. What is this Query object that it returns? -- 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.
