By the way, I'm all for the new array syntax, as suggested by Yehuda.
If the new syntax can cover just about any complex SQL query, I
wouldn't mind so much being "forced" to never use SQL, but at some
point it translates to SQL anyway, so why not allow the programmer
access to that level if he wants/needs it?
In order to get this to work for me, I had to copy the method from
datamapper that generates and executes the query, and I monkey-patch
it into a find_by_sql -- only because the sql query I needed to do was
too complex for the current query syntax. I don't think this use case
is so far out there -- plenty of people will need to execute complex
queries now and then -- we just have to find the right way to do it.
The monkey-patch I made worked great. In most cases it won't be a
problem (because if datamapper's migration creates the table, the
columns are all in the right order already), and if it is a problem
for someone, they can manually write the column order into the SQL and
it will behave as it should.
I'd love if the new syntax was in place, but also a find_by_sql method
that comes with a warning: "You'd better know what you're doing if you
use this because you could mix up the attribute order by
accident." (Unless we read the column names in the query and read the
incoming data appropriately...)
~Daniel
On Sep 2, 8:20 am, Mike Summers <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
