Re: [Django] #34117: Anomaly with makemigrations

[Django]

#34117: Anomaly with makemigrations
-+-
 Reporter:  Ismael ABBO  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  CustomUser, field,   | Triage Stage:
  anomaly|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid
 * component:  Database layer (models, ORM) => Migrations


Comment:

 You have a trailing comma after the field's closing parenthesis which
 creates a tuple and thus it isn't detected as a field. In the future,
 please see TicketClosingReasons/UseSupportChannels for ways to get help
 debugging and create a ticket only for confirmed bugs. Thanks!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701840c387e5e-1fb8ac69-578b-47b0-8c6d-f46130838942-00%40eu-central-1.amazonses.com.

Re: [Django] #34117: Anomaly with makemigrations

[Django]

#34117: Anomaly with makemigrations
-+-
 Reporter:  Ismael ABBO  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  CustomUser, field,   | Triage Stage:
  anomaly|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Ismael ABBO:

Old description:

> == Problem
> Makemigrations command does not see the specific change on models related
> to this field below but produces migrations for any other fields (even in
> separated project):
>
> {{{
> gender = models.BooleanField(
> _('gender'),
> default=True,
> blank=True,
> help_text=_('Designates whether the user is a woman.'),
> ),
> }}}
>
> Adding in migration files works fine, but {{{default}}} value does not
> (while they're applied in ORM according to
> [https://docs.djangoproject.com/en/4.1/ref/migration-
> operations/#addfield])
> Then I have added {{{blank=True}}} to counter non-null constraint
> violation
>
> When I add gender field in the migration files manually, executing
> {{{makemigrations}}} command again generate a delete of that field
> {{{gender}}} while I have not removed it in the associate model. **Do we
> assume here that it does not see the field at all from the beginning? **
> **Please, why? Am I wrong somewhere? **
>
> == Steps to reproduce with my environment project (but optional because I
> have tried it in separated project aswell):
> - dockerized Postgres 14.4
> - dockerized Python 3.8
> - Use a CustomUser model by following these instructions (which works
> well) : [https://code.djangoproject.com/ticket/25313#comment:24]

New description:

 == Problem
 Makemigrations command does not see the specific change on models related
 to this field below but produces migrations for any other fields (even in
 separated project):

 {{{
 gender = models.BooleanField(
 _('gender'),
 default=True,
 blank=True,
 help_text=_('Designates whether the user is a woman.'),
 ),
 }}}

 Adding in migration files works fine, but {{{default}}} value does not
 (while they're applied in ORM according to
 [https://docs.djangoproject.com/en/4.1/ref/migration-
 operations/#addfield])
 Then I have added {{{blank=True}}} to counter non-null constraint
 violation

 When I add gender field in the migration files manually, executing
 {{{makemigrations}}} command again generate a delete of that field
 {{{gender}}} while I have not removed it in the associate model. **Do we
 assume here that it does not see the field at all from the beginning? **

 When forcefully staying with that field, trying to run a command to
 populate database produces :
 {{{
   File "/usr/local/lib/python3.9/site-packages/django/db/models/base.py",
 line 503, in __init__
 raise TypeError("%s() got an unexpected keyword argument '%s'" %
 (cls.__name__, kwarg))
 TypeError: User() got an unexpected keyword argument 'gender'
 }}}

 **Please, why? Am I wrong somewhere? **

 == Steps to reproduce with my environment project (but optional because I
 have tried it in separated project aswell):
 - dockerized Postgres 14.4
 - dockerized Python 3.8
 - Use a CustomUser model by following these instructions (which works
 well) : [https://code.djangoproject.com/ticket/25313#comment:24]

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701840bd8627a-7cbe7de8-7bd2-4edc-b5a1-3ed407907722-00%40eu-central-1.amazonses.com.

[Django] #34117: Anomaly with makemigrations

[Django]

#34117: Anomaly with makemigrations
-+-
   Reporter:  Ismael |  Owner:  nobody
  ABBO   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|   Keywords:  CustomUser, field,
   Severity:  Normal |  anomaly
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 == Problem
 Makemigrations command does not see the specific change on models related
 to this field below but produces migrations for any other fields (even in
 separated project):

 {{{
 gender = models.BooleanField(
 _('gender'),
 default=True,
 blank=True,
 help_text=_('Designates whether the user is a woman.'),
 ),
 }}}

 Adding in migration files works fine, but {{{default}}} value does not
 (while they're applied in ORM according to
 [https://docs.djangoproject.com/en/4.1/ref/migration-
 operations/#addfield])
 Then I have added {{{blank=True}}} to counter non-null constraint
 violation

 When I add gender field in the migration files manually, executing
 {{{makemigrations}}} command again generate a delete of that field
 {{{gender}}} while I have not removed it in the associate model. **Do we
 assume here that it does not see the field at all from the beginning? **
 **Please, why? Am I wrong somewhere? **

 == Steps to reproduce with my environment project (but optional because I
 have tried it in separated project aswell):
 - dockerized Postgres 14.4
 - dockerized Python 3.8
 - Use a CustomUser model by following these instructions (which works
 well) : [https://code.djangoproject.com/ticket/25313#comment:24]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701840bd53010-cfcb805e-b950-468c-8614-b19de6c9070e-00%40eu-central-1.amazonses.com.