Jacques,
Yeah sorry, there's a lib that i wrote to manage class and module path
traversal which i had intended to include into extlib which i don't have
access to (and also it's been pointed out to me that extlib is eventually
going to be depreciated anyway).  I've got the lib included in SugarGlider
in my local copy but i haven't pushed it up yet.

Unfortunately, some of the changes in 10.1 broke my ability to operate w/
queries and their conditions, so i'm trying to hack a path through there,
and i'll be able to get SugarGlider put back together, and committed.

Mark,

Just map () to {} and , to ; mentally.  That's the ancillary difference.
 The important differences are that you're not using symbols anymore for
keys, and you use actual operators, rather than the hash arrow =>

-Ted

On Fri, Oct 2, 2009 at 11:36 PM, MarkMT <[email protected]> wrote:

>
> I agree that it would be great to have a nice way to handle these
> kinds of queries. I'm struggling a bit with the particular syntax
> you've proposed, but maybe I just need to stare at it a bit longer.
>
> Mark.
>
> Ted Han wrote:
> > 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to