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 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 -~----------~----~----~----~------~----~------~--~---
