Thanks! Very helpful! Any idea where a very experienced SQL coder can find a few details beyond the three pages of model/queryset documentation? Such as information on a) SQL CASE statements (or equivalent), b) performing LEFT JOINs (or equivalent). Would studying the source code be my best option?
On May 1, 2:03 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Fri, 2009-05-01 at 10:48 -0700, jrs_66 wrote: > > Hi, > > > Any pointers as to where I could find any info about performing a SQL > > CASE statement using Django? Even more fundamental... is there really > > no way of doing a LEFT OUTER JOIN in Django (other than terribly > > sloppy role your own hacks)? Does anyone know of any more complete > > model/queryset docs out there, other than the 3 pages Django offers? > > Your point of view is a little skewed here -- it's not particularly > useful to think in terms of "how do I turn this SQL into Python". > > Django's ORM provides a way to map particular pieces of Python > functionality onto the persistent storage layer, which happens to be (by > default at the moment) SQL databases. The goal isn't to provide every > piece of SQL in an equivalent form. Rather, the goal is to provide a way > to do various things that are useful at the Python level. > > So what's the model-related situation where a case-statement is going to > be necessary? I know some exist, but I'm interested in which particular > problem you're trying to solve so that we can help with a solution that > fits well with Django. Right now, there is no situation where Django > creates a "CASE" clause. Maybe in the future, if there's a common-enough > functional situation that requires it, it could be added. Providing some > context here will be useful. > > If you know precisely the SQL you want to write, then use SQL to conduct > the query. It's a perfectly fine language for that and it would be > redundant to to duplicate that in Django. > > As for left outer joins, Django uses them when it's necessary for the > query and uses inner joins at other times. This is a case where the ORM > does the right thing to implement the Python functionality and the > caller doesn't have to worry about it. > > So what is the specific problem you are trying to solve that requires > explicitly specifying an outer join? Once again, details will help us to > help you. > > > > > Also, am I alone in being a bit wary of the django ORM after > > reading... > > Yes, you are. > > > > > 'By default, a QuerySet will not eliminate duplicate rows. In > > practice, this is rarely a problem, because simple queries such as > > Blog.objects.all() don't introduce the possibility of duplicate result > > rows. However, if your query spans multiple tables...' > > > Is someone out there really serious in assuming that using DISTINCT is > > 'rarely a problem' due to most queries not needing to go beyond > > 'Blog.objects.all()'? Maybe I'm odd, but rarely do I have much use > > for a single table query... not the other way around... > > Django behaves the same way as most experienced SQL writers. Using > DISTINCT in a query can be avoided in a very large set of cases. It also > introduces a lot of extra work into the query (since a sort is > required). As SQL is about sets of rows, specifying things so that the > duplicate rows aren't selected in the first place is preferred, rather > than having to eliminate them from the result set. > > Single versus multi-table queries has no relevance to your question > here. It's fairly common to have multi table queries created by Django > and duplicate rows are only returned in very rare situations. > > What is the specific problem area you are working in that is routinely > returning duplicate entries and where distinct() isn't solving the > problem? > > > Not trying to be negative, > > And yet you're succeeding without any effort at all! > > Could you perhaps dial the attitude back a bit with all the "are you > seriously..." stuff? Suffice it to say that Django is being used for at > least a few thousand quite serious projects in more situations than you > or I can imagine and by some organizations that even you would probably > consider "serious". > > > but I'm struggling with making the ORM > > useful beyond quite simple (almost trivial) queries. > > Practice makes perfect. > > > The ORM seems to > > inevitably produce some seriously sloppy SQL under the covers. > > Concrete details are appreciated. I would dispute your claim, by the > way, so what are the models you're using and the querysets you're > constructing? > > At the end of the day, if Django isn't meeting your requirements, you > should definitely look at some other options, however, none of the items > you've posted really have enough details to allow us to suggest whether > there are any obvious improvements. However, most of the things you've > mentioned simply aren't issues in the majority situations I'm aware of > (and I've seen and worked with both some very small sites and some huge > ones), so generalisations aren't really appropriate. Asking questions > about specific cases where you can provide a short self-contained code > fragment to show what you're doing will be much more beneficial to all. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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 -~----------~----~----~----~------~----~------~--~---
