I have a simple example that is giving me some trouble. When a project
has multiple instances of an application referenced by patterns nested
more than one level deep it seems impossible to look up using reverse
() with only two path components. No matter what the current_app
argument is set to.
A
I have a dynamically generated search form which constructs Q()
objects at runtime. This works brilliantly in almost every case. There
is a particular combination of these objects which appears to create
an extra where clause though. Currently this isn't killing me because
the clause is simply a d
First let me start by referencing another ticket already in the wild.
http://code.djangoproject.com/ticket/8213
This updates list_select_related to accept a tuple which will be used
for the select_related call. Jacob proposes simply overriding the
queryset() method which is fine in most cases. An
e now, at least mine appears to have a unique
constraint on it right away.
This is still a legitimate issue during serialization, it's great to
see someone has made steps in the right direction.
On Feb 11, 3:45 pm, Eric Holscher wrote:
> On Wed, Feb 11, 2009 at 1:48 PM, jameslon
There is a small road block that makes contenttype a little dangerous
to use during application development. Especially in regards to
serializing your data to different databases. During syncdb the
contenttypes are generated in a way that makes regeneration at a later
date inconsistent with the pr
