add_constraint=False on relation fields
Adys
add_constraint=False (default True, normal behaviour) to FKeys/
M2Ms/...
As the tin says, it prevents index/constraint creation for that field.
I won't bother going through the use cases for this; I know I need it
and maybe other people too. I was wondering if any of you were
interested in implementing this to Django a more serious way, in which
case I could send my patch as a starting point (it's a hack, and only
works with postgres).
You know, giving the user more choice and all..
Malcolm Tredinnick
> I made a small patch for my local Django install to be able to precise
> add_constraint=False (default True, normal behaviour) to FKeys/
> M2Ms/...
> As the tin says, it prevents index/constraint creation for that field.
> I won't bother going through the use cases for this; I know I need it
> and maybe other people too.
No, actually the only way something like this is ever going to get into
Django is precisely because there are compelling use-cases. "I need it"
is not a compelling use-case, because the only way I can currently think
of needing this is if somebody is trying to change the very meaning of
what one-to-one and foreign key relations are (e.g. the recent
discussion about wanting non-unique one-to-one fields, which is
basically a contradication in terms). You might be after some effect
that is better achieved by not using these particular relational fields
and adding an option to those fields simply to achieve those effects
isn't a solution to any problem.
This isn't likely to get a lot of eyeballs and consideration until after
1.1 in any case, but at that time, you probably want to have explain
these use-cases and why you aren't changing the very meaning of the
relation fields.
Regards,
Malcolm
Richard Smith
Richard Smith
Shai Berger
(edited to correct top-posting):
> On Mon, Apr 6, 2009 at 6:15 PM, Malcolm Tredinnick wrote:
> >
> > On Mon, 2009-04-06 at 04:53 -0700, Adys wrote:
> > > I made a small patch for my local Django install to be able to precise
> > > add_constraint=False (default True, normal behaviour) to FKeys/
> > > M2Ms/...
> > > As the tin says, it prevents index/constraint creation for that field.
> > > I won't bother going through the use cases for this; I know I need it
> > > and maybe other people too.
> >
> > No, actually the only way something like this is ever going to get into
> > Django is precisely because there are compelling use-cases.
>
> what would the use cases be?
>
Django relation fields provide two sets of functionalities. One is the
definition of referring columns and the accompanying constraints (and perhaps
indexes); the other is the use of the referring columns in joins, to fetch
related records from the database. It may seem logical to separate the two in
some instances. However, I have yet to see the case where the wish for such
separation is not the result of a database design mistake.
I have run into one example case, where historic (versioned) data was
involved. As SQL support for history of records is nothing to write home
about, mistakes (from a true-relational, theoretic viewpoint) are almost
inevitable; you are forced to choose between evils.
However, since Django is higher-level, I think the solution, even in such
cases, should be with a better abstraction of what you try to achieve, rather
than introducing breakage into foreign keys; generic foreign keys may be a
model for such higher abstractions.
My 2 cents,
Shai.