unique_together with None

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

unique_together with None

gentlestone

if I have

unique_together = ('some_fk_field', 'some_plain_field')

and

some_fk = ...(null = True)

the system allows put more intsances with some_fk_field=None and the
same some_plain_field value

I think, this is a bug. Or how can I manage to allow just one instance
with null fk and the same other field value?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: unique_together with None

Gustavo Henrique

Try also: null=True, blank=True


--
Gustavo Henrique
http://www.gustavohenrique.net
http://blog.gustavohenrique.net

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: unique_together with None

gentlestone

On 11. Aug, 15:01 h., Gustavo Henrique <[hidden email]> wrote:
> Try also: null=True, blank=True
>
> --
> Gustavo Henriquehttp://www.gustavohenrique.nethttp://blog.gustavohenrique.net

blank=True ... I have had, but this one doesn't solve the problem,
maybe the problem is in postgresql, the associated SQL code for
postgresql is

CREATE TABLE ...
...
UNIQUE ("some_fk_field_id", "some_plain_field"),

and this apparently doesn't work
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: unique_together with None

Alex Gaynor

On Tue, Aug 11, 2009 at 8:25 AM, gentlestone<[hidden email]> wrote:

>
> On 11. Aug, 15:01 h., Gustavo Henrique <[hidden email]> wrote:
>> Try also: null=True, blank=True
>>
>> --
>> Gustavo Henriquehttp://www.gustavohenrique.nethttp://blog.gustavohenrique.net
>
> blank=True ... I have had, but this one doesn't solve the problem,
> maybe the problem is in postgresql, the associated SQL code for
> postgresql is
>
> CREATE TABLE ...
> ...
> UNIQUE ("some_fk_field_id", "some_plain_field"),
>
> and this apparently doesn't work
> >
>

You are talking about in the forms/admin validation correct?  Thinking
to how this is implemented there likely is a bug where this doesn't
use the SQL concept of NULL != NULL and uses the Python None == None
instead, which of these behaviors is correct I'm not sure of (though I
lean towards the SQL interpretation).

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: unique_together with None

Karen Tracey-2
On Tue, Aug 11, 2009 at 10:40 AM, Alex Gaynor <[hidden email]> wrote:

On Tue, Aug 11, 2009 at 8:25 AM, gentlestone<[hidden email]> wrote:
>
> On 11. Aug, 15:01 h., Gustavo Henrique <[hidden email]> wrote:
>> Try also: null=True, blank=True
>>
>> --
>> Gustavo Henriquehttp://www.gustavohenrique.nethttp://blog.gustavohenrique.net
>
> blank=True ... I have had, but this one doesn't solve the problem,
> maybe the problem is in postgresql, the associated SQL code for
> postgresql is
>
> CREATE TABLE ...
> ...
> UNIQUE ("some_fk_field_id", "some_plain_field"),
>
> and this apparently doesn't work
> >
>

You are talking about in the forms/admin validation correct?  Thinking
to how this is implemented there likely is a bug where this doesn't
use the SQL concept of NULL != NULL and uses the Python None == None
instead, which of these behaviors is correct I'm not sure of (though I
lean towards the SQL interpretation).

I don't believe there is a bug.  The original description of the problem confused me because I thought it was trying so specify unique_together for a field in one model and a field in another model related by a nullable foreign key, and I didn't think you could do that.  In fact you can't -- all the fields have to be in the same model/table and I see now that the original report wasn't saying that.  (The _field in the unique_together spec is what confused me as I read that as having a double underscore.)

Anyway, form validation allows multiple allows multiple None/NULL values here since most of the database backends interpret NULL != NULL at the SQL level to mean that (NULL, v1) != (NULL, v1) when doing multiple field unique checks.  The one exception I know of is Oracle, it apparently will raise an IntegrityError for this case.  See the discussion here:

http://code.djangoproject.com/ticket/9039#comment:10

Karen

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: unique_together with None

gentlestone

Thank you for the explanation. Seems to be the correct solution of the
problem (NULL, v1) != (NULL, v1) is overwrite the save method and
check for existence of (NULL, v1) before saving a new instance of
(NULL, v1). What I don't understand, why are the well-known databases
so stupid and why they can't do this job. What about make this pre-
save chceck as statndard behavior in Django?

On 11. Aug, 16:57 h., Karen Tracey <[hidden email]> wrote:

> On Tue, Aug 11, 2009 at 10:40 AM, Alex Gaynor <[hidden email]> wrote:
>
> > On Tue, Aug 11, 2009 at 8:25 AM, gentlestone<[hidden email]>
> > wrote:
>
> > > On 11. Aug, 15:01 h., Gustavo Henrique <[hidden email]> wrote:
> > >> Try also: null=True, blank=True
>
> > >> --
> > >> Gustavo Henriquehttp://www.gustavohenrique.nethttp://
> > blog.gustavohenrique.net
>
> > > blank=True ... I have had, but this one doesn't solve the problem,
> > > maybe the problem is in postgresql, the associated SQL code for
> > > postgresql is
>
> > > CREATE TABLE ...
> > > ...
> > > UNIQUE ("some_fk_field_id", "some_plain_field"),
>
> > > and this apparently doesn't work
>
> > You are talking about in the forms/admin validation correct?  Thinking
> > to how this is implemented there likely is a bug where this doesn't
> > use the SQL concept of NULL != NULL and uses the Python None == None
> > instead, which of these behaviors is correct I'm not sure of (though I
> > lean towards the SQL interpretation).
>
> I don't believe there is a bug.  The original description of the problem
> confused me because I thought it was trying so specify unique_together for a
> field in one model and a field in another model related by a nullable
> foreign key, and I didn't think you could do that.  In fact you can't -- all
> the fields have to be in the same model/table and I see now that the
> original report wasn't saying that.  (The _field in the unique_together spec
> is what confused me as I read that as having a double underscore.)
>
> Anyway, form validation allows multiple allows multiple None/NULL values
> here since most of the database backends interpret NULL != NULL at the SQL
> level to mean that (NULL, v1) != (NULL, v1) when doing multiple field unique
> checks.  The one exception I know of is Oracle, it apparently will raise an
> IntegrityError for this case.  See the discussion here:
>
> http://code.djangoproject.com/ticket/9039#comment:10
>
> Karen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: unique_together with None

Malcolm Tredinnick

On Tue, 2009-08-11 at 23:36 -0700, gentlestone wrote:
> Thank you for the explanation. Seems to be the correct solution of the
> problem (NULL, v1) != (NULL, v1) is overwrite the save method and
> check for existence of (NULL, v1) before saving a new instance of
> (NULL, v1). What I don't understand, why are the well-known databases
> so stupid and why they can't do this job.

Um .. the well-known databases are doing exactly the right thing. The
behavior of NULL is well-defined to be not equal to itself (Oracle's
incorrect behavior here is for historical reasons and they won't change
it to avoid backwards-incompatibilities for their existing long-time
users). Using nullable columns in unique constraints carries this
risk-tradeoff with it, if you are going to be inserting NULL-able items.

If you want to add that check to your save() method, then you can
override it yourself, but the database behavior is a matter of least
obstruction for users, since two entries of (NULL, "xyz") *are*
different at that level. You don't want that behaviour, but that doesn't
mean it's incorrect for all situations.

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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---