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 ? ) 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. We (including you) need to have basic tools to see what's going on in the query. Just as we need to know where exceptions happened, what the callstack looks like when shiznitt blows up and what templates and vars were involved. Why is the ORM different than looking at the context variables in a template ? This is automatic transmission and we need to see exactly what our high-level commands are resulting in. That is NOT a failure of the ORM. My point is also that you should not separate us from you. We are not end users. Some of us are damned smart and we might improve something in django's ORM, find a bug, or tune our django-ORM calls. Look, its not hyperbole to say its essential. Getting the SQL that is generated is very basic and essential. These are db driven apps. I'm just letting you know: I was stunned that I had to spend so much time searching and that both you and James Bennet replied "oh .... you don't". As though magical ponies would soon come and proffer the data to us. We'll be napping in our plush purple fields as the ponies come bring us our query sets. 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. > > My suggestion is simply that there be a public utility function > > somewhere that can remain stable. > > Point taken, but please understand that it's hard to provide a stable > utility function for unstable internals. But that's exactly why Y'ALL (rather than me or some snippet or blog post) should provide said function in the django distribution, up to date, always working for the distribution the person has dutifully downloaded. Internals should be free to be refactored. That's what public API calls are for. Its the alternative to putting the function on the QuerySet (since QuerySets wish to remain sql-agnostic, may connect in the future to other non-db entities and perhaps even to data sources from other lifeforms that do not comprehend this simplistic "relational" crap of humankind. relational implies an illusionary separation, a division of Godhead, lost in the realms of ignorance and needless division ) It is BECAUSE internals should be allowed to change that you offer a public function that works as advertised. > >> That said: > > >> print object.query > It works fine - if you do what I said to do. oh right, you said the magic word "print". which invokes the god of transformation .... unicode ? or repr ? IMO this is transferring what should be explicit methods and functionality into a basic function: print or string representation. if the desired effect is to get a SQL query string then a method should be named that and should deliver that. transformational functionality should not utilize unicode or repr as means to achieve this. this might be a python disease. notice that I didn't even notice that "print" was REQUIRED. my assumption is that .query was the result and you were just printing it for me. print should be simply to print in whatever format makes sense for the object involved, not to magically transform into a different creature and print that. and its infuriating when debugging yesterday I was dealing with an object in a filter: Apt.objects.filter(id__in=[1,2,3,4]) the [1,2,3,4] gets printed, but that isn't what it IS. no its ... some kind of weird query set. you have to constantly use obj.__class__ because you can't TRUST print or repr() another half hour of my life wasted. (I'm just being honest. I'm a djangoista ! django rocks man !) >The magic is in the __str__ function. grrrrrrrrrrrrrrrrrrrrrrr. Harry Potter magic shite, I tell you. anyway, thanks very much for all your work and your reply > > 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.
