Improved find conditions syntax in rails core

Hey guys, I was told to move discussion to the mailing list. I
recently started working with merb and datamapper and I am really fond
of moving the super simple conditions syntax over to rails.

Here is the (closed) ticket:

http://rails.lighthouseapp.com/projects/8994/tickets/335-improve-conditions-hash-to-support-more-complex-queries

Here are some examples of the syntax in action:

Person.find(:all, :conditions => { :age.gt => 30, :name.like => "%name
%" })
Person.all(:conditions => { :name => "Bob", :age.gt => 25 })
Person.all(:conditions => { :name.eql => "Bob", :age.gt => 25 })
Person.all(:conditions => { :name.like => "%ob%", :age.lte => 55 })
Person.all(:conditions => { :name.like => "%ob%", :age.in => [55, 56,
57] })
Person.all(:conditions => { :name.like => "%ob%", :age.not => [55, 56,
57] })

While, I have built a plugin that works with Rails 2.1 and below, this
functionality is so simple and so elegant, I am interested in trying
to
get this into rails core.

Also, I find that this area is constantly changing which requires
constant maintenance of the plugin. I believe this simple fix would be
better suited to being in rails and it would benefit a lot of people
when they first start building queries.

The plugin is here: http://github.com/xgamerx/conditions_fu/tree/master

If I was willing to create the patch and the associated tests, would
this be able to be accepted into rails? Any thoughts or suggestions on
the matter?

it is mentioned this may be
redundant effort because of the plugin here:
http://github.com/nkallen/arel/tree

Now I could be wrong but while this plugin seems useful as does this:

http://github.com/zdennis/ar-extensions/tree/master/ar-extensions

Both seem a bit too heavy handed to be part of the actual rails
codebase. I am not convinced all that should be within the rails core.
I
am convinced that the simple ability to use conditions hashes while
being given the added flexibility of greater-than, less-than, like,
not,
etc should be.

-1 for being in core. My reasons are:

  1. we have to add methods on Symbol that are utterly useless outside of this concept;
  2. I don’t think I’m willing to sacrifice operators in SQL for their textual, shorthand equivalents;
  3. it is actually less readable and more confusing than writing whole SQL fragments;
  4. since there are so many variations of this (Ambition, Squirrel, ARel, …), each is best to stay a plugin.

+1 for Mislav's -1 :slight_smile:

I agree with Mislav that this shouldn't go in core, but I wonder if
there's something that can be added to core which makes this behavior
easier to override by plugins? This way it will be less likely to
break in future updates.

Also of note, there's talk of DataMapper changing their condition
passing to an array instead of a hash.

Regards

Ryan

Fair enough thanks for your input.