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
-~----------~----~----~----~------~----~------~--~---
