Re: Django 1.8 Migrations: AlterField Migration calls default callable for ForeignKey even when no Model Instances Exist
Hi, I think the issue is described in https://code.djangoproject.com/ticket/24182. On Tuesday, March 14, 2017 at 12:50:52 PM UTC-4, Dylan Young wrote: > > Steps to reproduce: > > Create Model > Make migrations > Add FK to model with a callable default that has some side effect (e.g. > creating the default instance in the database) > Make migrations > Migrate (or run tests on clean db) > Observe the side effect > > > I couldn't find this on the Bug Tracker. Is this still an issue in dev > branch? > > I haven't reproduced in a controlled test, but if this is something that > others have observed or think may be an issue, I can look into reproducing > cleanly. > > If this is the intended behaviour then documentation is needed, though I > don't see why it would be since defaults aren't enforced on the DB level. > > Note: it runs cleanly if the default is placed in an AddField migration. > > Best, > > Casey Meijer > > -- 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 stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0be300f3-374a-424f-b971-87c64a898274%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Opportunity to contribute in Django
Hi Jainesh, Have a look at this page which should give you an idea about where to start: https://docs.djangoproject.com/en/1.10/intro/contributing/#finding-your-first-real-ticket On Monday, 13 March 2017 13:52:34 UTC, Jainesh Patel wrote: > > Hello, > > I am a final year CSE student from PICT, Pune, India. I am very interested > in contributing to Django. > > It would really be very helpful if you suggest any ideas to work on or any > bugs to resolve from where I can start. > > Hoping to hear from you soon, and thanking you in anticipation. > > Thank you, > Jainesh Patel > -- 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 stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3ade1a0b-8d30-44a8-99e6-f0da19dff8e8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Feature idea: forms signals
I've put together a brief proof of concept here: https://github.com/seddonym/formsignals It demonstrates what you could do with post_init, post_clean and post_save signals, which I've also implemented in a fork of Django (no test coverage or documentation yet though). The concept it demonstrates is two apps, a blog app and a priority app. The priority app is a pluggable app, unknown to the blog app, that allows users to mark blog entries as 'priority', providing they also put the word "Priority" in the title. (Bizarre example but I wanted to demonstrate why you might want to use post_clean.) The main place to look is in the receivers file here: https://github.com/seddonym/formsignals/blob/master/formsignals/priority/receivers.py I don't think this is a nice as subclassing the form in the first place, but that's not an option unless the maintainer of the blog app has exposed a way of hooking into it. As you can see you get a fair amount of power to encapsulate different logic between apps with very little code. I think the use cases for pre_init, pre_clean and pre_save are more niche, but it probably makes sense to include them for completeness. Would value any comments! On Monday, 6 March 2017 19:08:29 UTC, David Seddon wrote: > > Hi all, > > One thing I've always found challenging with Django is to adjust the > functionality of forms from other apps. An example might be to add an > extra field to a login form provided by a third party module. > > What I end up doing is often overriding the urlconf, view and form class. > Or, worse, monkey patching the form class. > > A much nicer way to do this would be to add a few well chosen signals to > forms. > > Potential ones could be: > > - post_init > - post_clean > - post_save (for ModelForms) > > I'd be happy to do a pull request for this, but just wondered what people > think. > > David > -- 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 stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/eb1dd68c-7006-4141-bace-045b87562f18%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Django 1.8 Migrations: AlterField Migration calls default callable for ForeignKey even when no Model Instances Exist
Steps to reproduce: Create Model Make migrations Add FK to model with a callable default that has some side effect (e.g. creating the default instance in the database) Make migrations Migrate (or run tests on clean db) Observe the side effect I couldn't find this on the Bug Tracker. Is this still an issue in dev branch? I haven't reproduced in a controlled test, but if this is something that others have observed or think may be an issue, I can look into reproducing cleanly. If this is the intended behaviour then documentation is needed, though I don't see why it would be since defaults aren't enforced on the DB level. Note: it runs cleanly if the default is placed in an AddField migration. Best, Casey Meijer -- 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 stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPGJNu7QCVkQKT0xVwDjF-8ySb%2BM6_XDK37e8%2BX2OtDbS2OJ0Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
