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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
On Fri, Aug 1, 2008 at 11:18, Nathan <XGamerX10@gmail.com> wrote:> > 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] })-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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Aug 5, 2008 at 10:15 AM, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> -1 for being in core. My reasons are: > > we have to add methods on Symbol that are utterly useless outside of this > concept; > I don't think I'm willing to sacrifice operators in SQL for their textual, > shorthand equivalents; > it is actually less readable and more confusing than writing whole SQL > fragments; > since there are so many variations of this (Ambition, Squirrel, ARel, ...), > each is best to stay a plugin.+1 for Mislav's -1 :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 On Aug 5, 6:26 am, "Damian Janowski" <damian.janow...@gmail.com> wrote:> On Tue, Aug 5, 2008 at 10:15 AM, Mislav Marohnić > > <mislav.maroh...@gmail.com> wrote: > > -1 for being in core. My reasons are: > > > we have to add methods on Symbol that are utterly useless outside of this > > concept; > > I don''t think I''m willing to sacrifice operators in SQL for their textual, > > shorthand equivalents; > > it is actually less readable and more confusing than writing whole SQL > > fragments; > > since there are so many variations of this (Ambition, Squirrel, ARel, ...), > > each is best to stay a plugin. > > +1 for Mislav''s -1 :)--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Fair enough thanks for your input. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---