Thanks for all the thoughts and also for considering putting something
like this into the API. We would find it really useful. It is also the
kind of visibility into what is going on that I think is a good
practice for gems in general.
We can also pass back to datamapper information about the kinds of
optimization that need to be made on the postgres gem to avoid bad
performance from happening. Right now we are in the thick of it. We
have found that the order of certain things presents a 10x performance
problem. We don't really have enough visibility to make that
observation into tests and rules though. It is all just patched in.
We use the lazy load arrays as first class citizens using the & + -
operators to combine queries. It has made the switch to DataMapper
really worthwhile. But the lack of visibility given how fussy postgres
is, has been a real problem. The ideal situation for us would be to
have a #to_sql method on these lazy array objects. That way as we
combine queriers we can inspect the way that changes our sql.
To put this all in very tangible terms we do stuff like this:
Task.all(:visibitilty.gte => 3) + Task.all(:ownership => {:owner =>
some_user}) + ....
We would like to be able to look at the way each of these queries is
defined and also the way that these get constructed as they are
combined:
(Task.all(:visibitilty.gte => 3) + Task.all(:ownership => {:owner =>
some_user}) + ....).to_sql
or just more simply the parts
Task.all(:visibility.gte => 3).to_sql
With the info that Ted provided we built a Search class that can allow
us to inspect the structure of our sql, but not the actual subbed in
values. I am sure we could go ahead and sub those values in, and we
may have to. It does seem like a good ORM should provide this
visibility into the actual translation. That is what has always
appealed to me about Sequel as an ORM.
On Apr 28, 3:03 pm, "Xavier (DBIYF)" <[email protected]>
wrote:
> On 29/04/11 5:30 AM, Dan Kubb (dkubb) wrote:> 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 don't have any specific thoughts on the interface, but *something* in
> the public interface for this would be ace. We are using this currently
> in the case where we don't want to take the speed hit of instantiating
> DM objects and just want the raw structs for results.
>
> Xavier
--
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.
