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 <kmtra...@gmail.com> wrote:
> On Tue, Aug 11, 2009 at 10:40 AM, Alex Gaynor <alex.gay...@gmail.com> wrote:
>
> > On Tue, Aug 11, 2009 at 8:25 AM, gentlestone<tibor.b...@hotmail.com>
> > wrote:
>
> > > On 11. Aug, 15:01 h., Gustavo Henrique <gustavo...@gmail.com> 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 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to