On May 8, 2017 3:30 AM, <marcin.j.no...@gmail.com> wrote: Hi.
After upgrading to 1.11 I'm getting this error: FieldError: created_at cannot be specified for <MyModel> model form as it is a non-editable field. First of all, the model contains created_at field declared as DateTimeField(auto_now_add=True). Probably that's why it is non-editable. But I cannot set editable=True - the change has no effect. My application allows overriding "created_at" value, because there are more than one separate input channels, and I have such cases. Other relies on auto_now_add. I want to leave auto_now_add=True as is, and have possibility to override it. How to achieve that? This feature is built for a standard use of tracking when an object is created. At a more basic level, this field is really tracking when the record in the DB is created. For most apps, these two values are the same, will never differentiate, and can be tracked transparently as the same field. In your use case, these two values can be different. You really should have two fields to track this information. For example, a 'created_at' field would track when the object was created, which can be provided through some channel, or use the current time stamp as a default of it isn't provided. It would NOT use 'auto_now_add' because you don't want the system to control such behavior. Using a 'default' value in your situation of the current time stamp would be appropriate. It would allow you to override the value from another source, or keep it empty and emulate the behavior of 'auto_now_add', probably with no other code changes. You would also have another field, such as 'record_created_at', which WOULD use 'auto_now_add because you would never need/want to change it for auditing purposes. Any references to this object would use the 'created_on' field, as it probably does now. The other girls would only be used for reporting and auditing. PS. Somebody asked me why I'm considering leaving Django, and this is a real example of worst changes in Django in last years. Breaking compatibility and blocking a dev to do what he want. There is nothing wrong with overriding such value. In your use case, that's a bit of an unfair assessment. You're asking a built-in feature to support an atypical use case. Implementing the behavior you need should be trivial, and would likely better account for the various input channels for your data. I'd challenge your assertion that there is nothing wrong with updating this field. Audit fields that track this information should not be easily updated (otherwise you can't trust your audit trail), and it should be a deliberate design decision to be able to do so. Note that the Django devs don't 'block' you from doing anything, given that you can write code to do anything you want. You may encounter restrictions with the built-in functionality, but generally those restrictions are there for a good reason. If you're hitting those walls, it would be wise to determine why. I've found that the intentional limitations imposed by the Django devs lead to a much better design pattern, and those limitations are not imposed without extensive discussion on the dev mailing list or ticket tracker. -James -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVLLwLu2RwKF84qrg3zrjhkSStMyS7-R3y1vK0YQUdnjw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
