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 -~----------~----~----~----~------~----~------~--~---
