Hey dudes, i've broken my codebase back out (turns out i had a whole bunch of code i never checked in), and am reevaluating where things stand now that 10.2 is out and all that stuff.
A lot of the problems i was encountering had to do with poorly and inconsistently defined behavior when merging queries, which it appears has been addressed in the move from 10.1 or 10.0 (don't remember which) to 10.2. It looks like i can roll ahead with finishing my prototype of Sugar Glider, and i would be very much interested to hear opinions on how i've got it designed once i get it packaged up so other people can run it and test it. -T On Mar 19, 11:43 am, "Dan Kubb (dkubb)" <[email protected]> wrote: > trans, > > > Very cool. This is exactly the kind of syntax I'm talking about. But, > > yes, using AST is problematic. Looking it over, about 90% of this can > > be done in pure Ruby using meta-programming techniques. > > The things that can't be done with meta-programming are the > connectives like AND and OR, unless you use & and | instead of && and > || respectively. I think NOT can be handled in 1.9 because ! is now a > valid method, although I am not 100% sure. > > Ted Han (knowtheory) was working on an extended query syntax: > > http://github.com/knowtheory/dm-sugar-glider > > > I wouldn't mind working on it, but I'll need to understand a little more. > > What is > > this Query object that it returns? > > The Query object is what DataMapper creates under the hood when you > pass it a Hash object. It represents the query that will be executed, > and which model/repository it will be executed against. It stores > things like conditions, limit, offset, order, etc. You can think of it > sort of like an object that somewhat resembles a "SELECT" type query > in an RDBMS. There are objects to represent the normal connectives > like AND, OR, NOT, and operations like >=, >, ==, <, <=, among others. > > While the normal use-case is that a Query is constructed from a Hash, > it can also be build up as a tree. Think of each operation as a leaf, > and they are connected together in an arbitrarily deeply nested tree. > Every branch can be negated using NOT, or connected via AND and OR. > Most complex read queries can be constructed with this API, but it's > not typically used by end users; adapter authors and myself are > probably the people most exposed to this backend API. > > Check out the Query API for more information. Each method is > documented, along with the connectives and other operations, and there > are specs showing how to build up the Query tree. If you have any > questions feel free to ask on this mailing list, or on the IRC channel > #datamapper. > > -- > > Dan > (dkubb) -- 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.
