> However, the bigger issue is that I think changing the definition of > this field really requires a migration mechanism (which would update > existing databases), which we don't have. We really don't want the > situation of bugs which are impossible to reproduce because they > depend on installation and upgrade order.
This is a good point. On the other hand, If an existing application relies on last_login not being null it would most likely continue function faultlessly even if the table can be null. The only exception I can think of would be someone attempting to try/except an error to make sure last_login was is not null but this does not seem to be a common practice. I think new applications could benefit from removing not null constraint. And it seems to be rather safe to flip "null=False" without breaking backward compatibility (if password reset functionality is properly addressed). Cheers SK -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
