Re: [Django] #22555: Migration doesn't work when fields are added using contribute_to_class

[Django]

#22555: Migration doesn't work when fields are added using contribute_to_class
-+-
 Reporter:  Matt3o12 |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:
 Severity:  Release blocker  |  1.7-beta-2
 Keywords:  migration, fake, |   Resolution:  invalid
  __fake__, contribute_to_class  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by andrewgodwin):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 This isn't a Django bug (we've never documented or encouraged adding
 dynamic fields this way so we're not going to keep it backwards
 compatible), you need to work with the migration serialiser instead.

 The key thing is that Django will preserve fields as it sees them on the
 model at the time of the migration being created - which means that models
 that dynamically create fields and fields that dynamically create fields
 simply need to check and make sure the field they're trying to add isn't
 there already. It should be a one-line addition.

 In a more general sense, I would encourage extra fields like this to be
 explicitly declared on the model and passed in to the other field if it
 needs them - like the width and height fields for images. That's how
 Django expects fields to work and how migrations will work best.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.9b4da12fe0b73ce46a06ff0e2d47dde0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22555: Migration doesn't work when fields are added using contribute_to_class

[Django]

#22555: Migration doesn't work when fields are added using contribute_to_class
-+-
 Reporter:   |  Owner:  nobody
  Matt3o12   | Status:  new
 Type:  Bug  |Version:  1.7-beta-2
Component:   |   Keywords:  migration, fake, __fake__,
  Migrations |  contribute_to_class
 Severity:  Release  |  Has patch:  0
  blocker|  UI/UX:  0
 Triage Stage:   |
  Unreviewed |
Easy pickings:  0|
-+-
 When you create a custom Field that implements the `contribute_to_class`
 and add another Field that way, it won't be possible to use migration.

 The code I used:

 {{{
 #!python
 class MyField(models.CharField):
 def contribute_to_class(self, cls, name):
 if not cls._meta.abstract:
 field = CharField(max_length = 20)
 cls.add_to_class("%s_mycontribute" % name, field)


 super(MyField, self).contribute_to_class(cls, name)

 }}}

 What happens if the original model is used (`app.models.MyModel`):
 1. contribute_to_class is called and adds additional fields (in my
 example, `MyField`).
 2. contribute_to_class calls it super function and adds the original field
 (`CharField`).

  Everything works. The model has 2 fields: `MyField`, and `CharField`.

 ---

 When python tries to create a migration (now the model `__fake__.MyModel`
 is used).
 1. contribute_to_class is called. The model already has the contributed
 CharField (with the name %s_mycontribute) (why does the model already have
 it?).
 2. MyField with the exactly name is added again (and no exception is
 thrown?!).
 3. The original field (MyField) is added.

  The view now has 3 fields: `MyField`, `CharField`, and `CharField` again
 (both `CharField`s have the same name).
 The next step django does is trying to migrate my model but it fails with
 the exception: "django.db.utils.OperationalError: duplicate column name:
 charFile_mycontribute" because the field was created twice.


 My guess:
 The original model is somewhere copied and the fields in _meta are not
 cleaned correctly.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.4dbd894d4ec14171e9ea0396a1e43f50%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.