Kane, > 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.
What if there were Query#to_sql and Collection#to_sql methods? I've resisted a bit in the past, but I'd be willing to put them in to aid debugging and if it helped get some feedback on SQL generation. I very rarely get any feedback on how optimized the SQL generation is, and whether or not I'm doing something optimal for a specific database, or if there's a better approach. Since I'm working on SQL generation in Veritas at the moment, this subject concerns me greatly. I want to make sure I'm generating everything correct first (obviously), then using the most efficient approach. The work I'm doing is centered in https://github.com/dkubb/veritas/ and https://github.com/dkubb/veritas-sql-generator/ -- I've wrapped up most of the normal operations except aggregate and scalar functions. -- Dan (dkubb) -- 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.
