If we get to vote on this I'd go for directly exposed SQL (why two
syntaxes when one will do?) and then meta matching the result set
attributes to see if they don't fit some existing model object and
return as the model object rather than the array of structs.
If we go with the array sytax please add AND back in. Implicit
'features' are a maintenance problem.
--Mike
On Sep 2, 2:57 am, mayo <[EMAIL PROTECTED]> wrote:
> Would repository(:default).adapter.query(%Q{SELECT ... GROUP BY feed})
> do the same job for you? This way you get an array of Structs back, or
> am I missing something here? (It's pretty late, so I might be...)
>
> mayo
>
> On Aug 28, 10:19 am, Daniel Parker <[EMAIL PROTECTED]> wrote:
>
> > I would like to strongly suggest that we AT LEAST devise a way to get
> > at manually instantiating objects from sql results easier. I have one
> > app, for example, where I have to construct a pretty complex sql query
> > just to get the right objects, but at that point I'm grabbing whole
> > records anyway, so it'd just make sense to me to be able to easily
> > instantiate them into objects. I had to jump through all sorts of
> > hoops to make it (my find_by_sql method) work, and then the next
> > version jump of datamapper broke it. My example:
>
> > Message.find_by_sql("SELECT messages.* FROM messages INNER JOIN
> > (SELECT MAX(id) AS id FROM messages WHERE created_by =
> > '#{current_openid}' GROUP BY feed) AS ids ON messages.id = ids.id")
>
> > This basically selects the last-created message from each feed, only
> > referencing one table. It worked great, and I think is a good example
> > of something I have no other way of doing. BUT I'd rather instantiate
> > them into objects from the sql, and not have to do it entirely
> > manually.
>
> > Is there a possibility we can at least provide a "not-recommended-but-
> > available" way of doing it, and let developers shoot themselves in the
> > foot until they do it right, if they want to?
>
> > ~Daniel
>
> > On Jul 15, 5:23 pm, Science <[EMAIL PROTECTED]> wrote:
>
> > > Sam Smoot <[EMAIL PROTECTED]> wrote:
> > > > > > Right. That back-end needs a syntax however. Otherwise we're
> > > > > > expecting
> > > > > > everyone's syntax plugins to manipulate the Query#conditions AST
> > > > > > directly. Which is fragile.
>
> > > > > > Also, I've gotta say, I'm probably speaking from a position of CS
> > > > > > ignorance, but I have a sneaking suspicion that Ruby 1.9's ordered-
> > > > > > hashes is one of the less good design decisions the MRI team has
> > > > > > made,
> > > > > > forcing a memory/computation hit, when for most uses, it doesn't
> > > > > > matter. So MRI will be paying a penalty there for a very long time
> > > > > > to
> > > > > > come.
>
> > > > > > Either way, condition order is *very* important. So unless someone
> > > > > > can
> > > > > > suggest a syntax that works across VMs, and preserves order, I'm un-
> > > > > > moved from Yehuda's syntax. Plugins encouraged sure.
>
> > > > > > -Sam
>
> > > Sam - I brought up some related stuff on another thread but thanks for
> > > pointing me here.
>
> > > My opinion is that data mapper needs to support complex queries to the
> > > extent that it permits "distributed" query building. One of the issues
> > > I have is that building raw SQL is not very object oriented (duh) and
> > > so in my OO architecture where different query segments are
> > > constructed by various arms and legs of the objects, holding together
> > > all the SQL is fairly difficult. I solved this problem by creating a
> > > custom SQL object but it would be great to see Data Mapper support
> > > this kind of stuff natively. The syntax sugar, ParseTree and all that
> > > are fine but the real issue is that I need to do stuff like:
>
> > > * create a new clause called "foo" ("or'ed" to previous clause)
> > > * add several conditions to it
> > > * create a second new clause "bar"
> > > * add some conditions to it
> > > * go back to "foo" and add some more conditions in there
> > > * add two order by statements
> > > * set "distinct on (x,y,z)" to the front of the select list
> > > * add two more order by statements
> > > * specify several table join statements
>
> > > Being able to add SQL to the query in some order other than what SQL
> > > expects is really the big deal for me. It lets me design my
> > > application the way it "wants" to be built, rather than the way SQL
> > > would like the output.
>
> > > I hope this input is useful! Definitely drop me a line if I can
> > > clarify anything.
>
> > > Steve
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
