Django 3.1 Released

2020-08-04 Thread Mariusz Felisiak
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2020/aug/04/django-31-released/ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and s

FK field caching behavior change between 1.11.x and 2.x

2020-08-04 Thread Gert Burger
(initially posted to https://forum.djangoproject.com/t/fk-field-caching-behavior-change-between-1-11-x-and-2-x/3151 on 26 June but this mailing list might be more appropriate) Hi Whilst upgrading a codebase from 1.11.x to 2.0/2.2 I noticed a weird change in behavior of FK fields when copying

Re: FK field caching behavior change between 1.11.x and 2.x

2020-08-04 Thread charettes
Hello Gert, that seems a bit surprising to me and was likely not a desired change. Could you bisect the exact commit that caused the regression[0]? That would certainly help determining the action to take here. Thanks, Simon [0] https://docs.djangoproject.com/en/3.1/internals/contributing/tri

Re: FK field caching behavior change between 1.11.x and 2.x

2020-08-04 Thread Gert Burger
Hi Simon, I think the commit is bfb746f983aa741afa3709794e70f1e0ab6040b5 "Refs #16043 -- Refactored internal fields value cache". Cheers On Tue, 4 Aug 2020 at 15:52, charettes wrote: > Hello Gert, that seems a bit surprising to me and was likely not a desired > change. > > Could you bisect the

Exception [IntegrityError] - violates not-null constraint in email field

2020-08-04 Thread Francisco André
Hey guys. I'm developing a new project and creating a custom user model, extending the AbstractBaseUser class, but when add a new user in admin interface or modelform I get the error: IntegrityError at /null value in column "email" violates not-null constraint. The field email is necessary and

Re: FK field caching behavior change between 1.11.x and 2.x

2020-08-04 Thread charettes
It was likely overlooked by the patch. Looks like Model.__copy__ should make sure to make a deep-copy of self._state now that fields are cached in self._state.fields_cache. Using copy.deepcopy will circumvent the issue but I feel like copy.copy is common enough pattern that we should maintain c

Re: FK field caching behavior change between 1.11.x and 2.x

2020-08-04 Thread Alexander Hill
I reckon stick with your first instinct SImon. I don't think using copy.copy needs to be an explicitly documented pattern. It's a heavily-used part of the standard library, and the objects Django provides should work with it as well as they can. The behaviour is surprising and buggy at face value: