Or a "dump" method which adapters could optionally define? On 04/28/2011 12:44 PM, Ivan R. Judson wrote: > > Um; I'd rather an adapter method that's something more like: > > to_native_query(query) => SQL for RDBMS, but allows other query > languages too. > > Just my $0.02. > > --Ivan > > Ivan R. Judson > (406) 285-1395 Voice > (928) 569-3850 Fax > > > > On Thu, Apr 28, 2011 at 1:42 PM, Ted Han <[email protected] > <mailto:[email protected]>> wrote: > > Hey Kane, > > I've been chatting w/ dkubb a bit. Rather than a Query#to_sql > method i'd suggest having a #sql_from(query) method on adapters > (or whatever we call it). Do you have feelings on the subject? > > There's a bunch of stuff you can do with the Query API, but it's a > bit of a mess. I would be interested to know more about the > details about what you're trying to cleanup and the like, since > that'd be useful to know what improvements can be made to the SQL > generator and to the API in general. > > -T > > On Thu, Apr 28, 2011 at 3:12 PM, Kane Baccigalupi > <[email protected] <mailto:[email protected]>> wrote: > > We have a very big app in Sinatra. I set up logging when we > switched > to Datamapper, which is how we are able to look at our > development and > tests logs to determine the final SQL. That isn't what I am > looking > for, because we already have that. I am looking for a way, > preferably > in tests to be able to inspect the SQL string generated by ?query? > objects. Clearly the string is generated before it is sent to the > database, so where is that string so that we can make assertions > against it. > > Why would I want to do this? Did I mention that we have a very big > application? Some or our joins combine many datamapper query > objects > with intersection, or, and ... Very ofter postgres is fussy > about such > things as the order of clauses, sub-selects, requirements in > the where > clause. We are having performance issues related to this > fussiness, > and because we do test driven development, we would like to > match our > queries to assure no regressions as our code changes or we update > gems. > > So, Ted's solution is by far the best. Thanks Ted. > > I can build a method on our search object that does this kind > of thing > with less verbosity. But I would really like my query all put > together, with the question marks dumped supplanted already with > variables. This will be good enough, but I would love it all. > > -- > You received this message because you are subscribed to the > Google Groups "DataMapper" group. > To post to this group, send email to > [email protected] <mailto:[email protected]>. > To unsubscribe from this group, send email to > [email protected] > <mailto:datamapper%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/datamapper?hl=en. > > > -- > You received this message because you are subscribed to the Google > Groups "DataMapper" group. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To unsubscribe from this group, send email to > [email protected] > <mailto:datamapper%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/datamapper?hl=en. > > > -- > 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.
-- 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.
