On Tue, Feb 23, 2010 at 10:42 AM, felix <crucialfe...@gmail.com> wrote: > > On Feb 23, 12:32 am, Russell Keith-Magee <freakboy3...@gmail.com> > wrote: > >> To reinforce my point - if you're using Django's ORM, you shouldn't >> have to care about the underlying query. The ORM *should* be >> abstracting these details so that you don't care. I realize that >> inspecting query internals can be useful in practice, but from my >> perspective, every time you need to do this Django's ORM has failed a >> little bit. > > I would like my client and his clients not to care. > > I will need to care. I need to know exactly what queries are being > run and how long they took ( or would you outlaw things like debug > footer too ? )
... and here we have yet another example of the type of hyperbole I'm talking about. Django provides *several* ways to find out what SQL has been (or will be) executed. You can inspect QuerySet.query in several different ways (str(), get_compiler().as_sql()). There is the debug query log - which will tell you how long queries took to execute, as well as the SQL that was used. If those options don't suit, you can go to the database and look at the logs provided there. I have at no point claimed that you *shouldn't* be looking at the internals. I'm saying that the internals aren't part of the core API that we're trying to promote, and that trying to provide a stable API for inspecting unstable internals is a folly. > Look, I love the Django ORM, I'm having a great time. > > It is not a failure of the Django ORM, please don't think of it like > that. If the Django ORM is to succeed and improve then it will need > its programmers to have full access to it. Do you think race car > drivers don't know how their engines work ? Do you think they don't > know when they've changed gears? Don't you want some smart kid to > figure out how to optimize the queries even better ? The more info > and access, the better. Sure. But to continue your analogy, what you're advocating is that a racecar driver should have the same easy to use automatic gearbox and simple instrument panel that my grandmother has in her 1995 Honda Civic. If you're a racecar driver, part of your job is to pay attention to the internals, and to accept that in order for your car to go a little faster, you're going to need to pay attention to what the mechanics have done. Sometimes, this means the instrument panel will change, or you'll need to change your style when releasing the clutch. Besides - the internals of Django's query engine *are* completely exposed. They're just not officially stable. That said, they've been effectively stable since QSRF landed over two years ago. The arrival of multi-db has shaken things up a bit, and as a result, the anti-stall launch control that drivers like yourself have used in the past doesn't work like it used to. To demonstrate the scope of the problem - we could *easily* add an as_sql() function back onto Query, so that the old Author.objects.all().query.as_sql() trick would still work (def as_sql(self): return __str__(self)). However, the result returned by that call would be incorrect (or at least, potentially misleading) in the same way that the result returned by str(queryset.query) is wrong. So, what is better? 1) A consistent API entry point that provides inconsistent or incorrect results as the internals change 2) An inconsistent API that *occasionally* changes (and I do mean *occasionally*), but is able to reflect the changes in internals. Evidently, you support (1). I support (2) -- if only because a change in interface forces people to think about the change that has occurred, and the way that this change might affect them. > Look, its not hyperbole to say its essential. Getting the SQL that is > generated is very basic and essential. These are db driven apps. Yes, it really is hyperbole. You have always been able to get access to the SQL. You still can. Exactly *zero* production code should need to access or monitor the SQL that is being generated. Accessing the generated query is *entirely* a debugging activity for medium to advanced Django developers that are either trying to push the envelope of what Django's query engine can produce, or debug what Django is doing so they can patch the query engine. Neither of these activities require a stable API. They only require that the API be *available* -- which it is. > Can I pay the ponies no more than $3/hr ? They can be late and > occasionally wrong, I'll just make up some bullshit for my client. I'd be more than happy to be paid *at all*. Remember, I'm doing this as a volunteer. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
