You can only please some of the people all of the time or all of the
people some of the time. Having a way to write manual queries would
go a long way towards supporting the use-case Daniel describes, but I
think we need to keep in mind that DM can talk to any number of
persistent storage schemes, not just SQL-literate ones.
If we do add in find_by_sql functionality, I would suggest we call it
find_manually or something more query language generic. It may be
better left to a DM-More gem as well, since repository.adapter.query
and repository.adapter.execute already exist in DM-core and all it
would do is provide a cleaner API and fully instantiate the object
instead of returning Structs.
Anywho, my $0.02 worth.
===
Adam French
Project Manager
Wieck Media
On Tue, Sep 2, 2008 at 9:36 AM, Daniel Parker <[EMAIL PROTECTED]> wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
