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.