""" > The reason for doing the deprecation now is that it would be nice that > this behavior is already removed when multicolumn primary keys are > introduced into Django. > > There is a ticket related to this: #2259.
Here is another that could be helped by this change, depending on implementation - #14615 The decisions on that ticket basically boils down to the question of how we detect a new object (which is waiting for PK from the DB). The current solution of comparing with None (used in various places) fails for nullable primary keys. """ I can think of two basic approaches to this: define a __setattr__ for Models, and check if the pk is set after fetch from DB. This has at least three problems: 1. It is likely that users have custom __setattr__ methods that do not use super().__setattr__ but change the dict directly. 2. This way it is somewhat hard to detect if the PK has actually changed or not. You can (and many users likely currently do) set the value to the same value it is already. 3. This will make model __init__ slower (although there are tricks to mitigate this effect). The other way is storing old_pk in model._state, and compare the PK to that when saving. If changed, error. This would work best if there was a NoneMarker object for the cases where there is no PK from DB, so you could solve #14615 easily, too. This could result in somewhat larger memory usage. Although normally you could store the same string (or other object) in db_pk as you store in the __dict__ of the model. This would mean minimal memory overhead unless you change a lot of PKs in one go. Are there problematic (mutable object based) model fields, where you would need to store a copy of the field's value? We could possibly have an attribute "mutable object based field" for the problematic fields... One way to mitigate the speed effect is use of AST for model init. I have done some experiments about this, see: https://github.com/akaariai/ast_model. That does come with its own problems, but if templates are going to be using AST, then we could use it in other places needing speedups, too. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
