On Dec 16, 4:34 pm, "Sean O'Connor" <[email protected]> wrote: > Nice work Russ! Got to love when something goes from "nice to have" to > "done". > > Anssi, I don't think I understand your use case. Even if an unmanaged model > doesn't have a literal table behind it, it needs something which at least > resembles a table (i.e. a view) to query against. Otherwise the ORM will > generate errors regardless of the behavior of .raw().
If you have a model which will be populated ONLY using raw queries, then you don't need a backing view or table. And the use case is creating something resembling a database view purely in Django. > To answer your question, raw() determines what fields are populated by the > names of the columns returned by the database cursor. Accordingly, if you > want to pull different fields using different queries, you probably do so > using subqueries in one big SQL statement. As long as the field names > returned by the query match the field names in the model or you provide a > translations parameter to describe which query fields go to which model > fields it should work. But if I don't provide some of the field names in the select clause, and try to access a field that isn't included in the query, I will get a ProgrammingError: db table not found. > As far as allowing users to define raw queries for each field to allow them > to be deferred, this is way outside the scope of this patch. The goal of > .raw() was to provide some relatively simple syntactic sugar to make a > common class of raw queries easier. It was not intended to completely > replace all possible use cases for doing raw queries using a cursor. I am not suggesting this. What I would like to have is something like foo.field.is_deferred(). I don't think there is any easy way to test this currently. This could come handy in a template for example. You could use the same template for objects fetched with different raw queries, and skip deferred fields when showing data about the object. I haven't done any Django coding, but is_deferred() seems something that I might be able to do. I am not sure if this is something that is needed, though. Anssi Kääriäinen -- You received this message because you are subscribed to the Google Groups "Django developers" 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/django-developers?hl=en.
