Well... actually the important part is that it's block based querying. The
semicolons are just logical line breaks.
Human.all{ sex == "M"; any{ last_name == "Obama"; last_name == "Clinton" } }
could just as well be
Human.all do
sex == "M"
any do
last_name == "Obama"
last_name == "Clinton"
end
end
One nice additional benefit there, being the fact that you can execute
whatever you want within the block (warning there though, the scope for the
block internals isn't the same as the Model's scope).
Also, one effect that i'm not sure i'm entirely happy with, is the fact that
you can actually chain the statements together... Since the query is built
via side-effect, rather than return value (i know, my LISP prof is weeping
inside right now, though he knows not why). Example:
Human.all{ sex == "M" and any{ last_name == "Obama" or last_name ==
"Clinton" } }
So if you don't like semicolons, you could make it all one logical
statement.
Lastly, i'm not actually overriding Enumerable's #any? method, cause it's
#any? not #any. I'm concerned that will cause confusion, as we have just
encountered. If someone can propose a better name, i'm more than willing to
use it. However, all vs any is sort of the sensible pair.
The goal here really is to make querying DM more like using normal ruby.
Rather than throwing around these hashes with all these meaningless =>
arrows all over the place, you can use the actual operators you're used to.
On Fri, Oct 2, 2009 at 3:10 PM, Brian Smith <[email protected]> wrote:
> I really like the idea of overloading the any method. Not sure if using the
> semicolon in the middle of it is the best way to go about it. It seems odd
> to me. Might I suggest just passing n number of hashes to where each hash is
> a clause of the or query. Some of the syntax is a bit confusing in the
> current implementation.
>
>
> On Fri, Oct 2, 2009 at 7:34 AM, Ted Han <[email protected]> wrote:
>
>> I've got one half completed. It's a library called dm-sugar-glider.
>> Right now it allows you to do block based queries, and nested conditions,
>> using ANDs or ORs.
>>
>> I'll post to the list when it's done. (I've got the in model property
>> matching down, i'm wrestling with some internals in core to sort out the
>> matching w/ relationships) It will require people to bump up to edge
>> though.
>>
>> Examples:
>>
>> original = Human.all(:last_name => "Obama", :first_name => /a/)
>> mixed = Human.all(:last_name => "Obama"){ first_name =~ /a/}
>> block = Human.all{ last_name == "Obama"; first_name =~ /a/}
>> mixed.query.should == original.query
>> block.query.should == original.query
>>
>> Human.all{ first_name =~ /ar/; sex == "F" } # => Hillary, Barbra,
>> Barb
>> Human.any{ first_name =~ /ar/; sex == "F" } # => Barack + ALL women
>> Human.any{ sex == "M"; all{ first_name == "Barbra"; dob == "June 8,
>> 1925" }} # All men + the elder Barbra Bush
>> Human.all{ sex == "M"; any{ last_name == "Obama"; last_name ==
>> "Clinton" } } # Barack Obama + Bill Clinton
>>
>> On Fri, Oct 2, 2009 at 8:09 AM, Jacques Crocker <[email protected]>wrote:
>>
>>>
>>> Ok, so the error that is being thrown is a result of a different issue
>>> (isolated and discussed in another thread).
>>>
>>> Question is still open though, is there a better way to write OR
>>> queries in datamapper 0.10?
>>>
>>> Thanks!
>>>
>>>
>>> On Oct 2, 4:34 am, Jacques Crocker <[email protected]> wrote:
>>> > Via Datamapper 0.10, is there a mechanism to better handle
>>> > conditionals with OR (instead of AND)?
>>> >
>>> > I had my ghetto search query break from 0.9 to 0.10:
>>> > all(["(title like ? OR description_source like ? OR company_name
>>> > like ? OR outside_location like ?)", search, search, search, search])
>>> >
>>> > I know there's the much fancier :name.like => "" , however I
>>> > couldn't figure out how to make it work with an OR query. Can anyone
>>> > help?
>>> >
>>> > Here's the stack trace I get on the above query. the search variable
>>> > is just a simple string
>>> > ~ Binding mismatch: 2 for 1
>>> > INTERNAL ERROR!!! Binding mismatch: 2 for 1
>>> >
>>> /Users/jc/Merb/testapp/gems/gems/data_objects-0.10.0/lib/data_objects/
>>> > command.rb:73:in `escape_sql'
>>> >
>>> /Users/jc/Merb/testapp/gems/gems/dm-core-0.10.0/lib/dm-core/adapters/
>>> > data_objects_adapter.rb:88:in `execute_reader'
>>> >
>>> /Users/jc/Merb/testapp/gems/gems/dm-core-0.10.0/lib/dm-core/adapters/
>>> > data_objects_adapter.rb:88:in `read'
>>> >
>>> /Users/jc/Merb/testapp/gems/gems/dm-core-0.10.0/lib/dm-core/adapters/
>>> > data_objects_adapter.rb:266:in `with_connection'
>>> >
>>> /Users/jc/Merb/testapp/gems/gems/dm-core-0.10.0/lib/dm-core/adapters/
>>> > data_objects_adapter.rb:84:in `read'
>>>
>>>
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
