Closed electroniceagle closed 8 years ago
which djangocms-blog versions are you migrating from / to ?
I'm trying to migrate to djangocms-blog==0.8.7 from 0.8.6. However, it isn't migrate command that is effected, it is when you manage.py makemigrations
.
Yeah, I meant upgrading
@electroniceagle confirmed. Thanks for spotting this. 0.8.8 is on the way
@electroniceagle could you please test https://github.com/nephila/djangocms-blog/archive/hotfix/thumbnail_model.zip ?
Still the same exception as above. I'm now debugging with python -m pdb manage.py makemigrations --dry-run
to trace. Will post some more state soon.
(Pdb) p self._pending_lookups.items()
[((u'cmsplugin_filer_image', u'ThumbnailOption'), [(<class 'Post'>, <django.db.models.fields.related.ForeignKey: main_image_full>, <function resolve_related_class at 0x111df9758>), (<class 'Post'>, <django.db.models.fields.related.ForeignKey: main_image_thumbnail>, <function resolve_related_class at 0x111df9ed8>)])]
(Pdb) app_configs[35].models['post'].main_image_thumbnail.field.__dict__
{'_validators': [], 'auto_created': False, 'serialize': True, '_unique': False, 'unique_for_year': None, 'blank': True, 'help_text': u'', 'null': True, 'to_fields': [None], 'db_tablespace': '', 'db_index': True, 'is_relation': True, 'unique_for_month': None, 'unique_for_date': None, 'primary_key': False, 'concrete': True, 'swappable': True, 'max_length': None, 'rel': <ManyToOneRel: djangocms_blog.post>, 'from_fields': [u'self'], 'verbose_name': u'main image thumbnail', '_choices': [], 'creation_counter': 157343, 'editable': True, 'error_messages': {u'unique': <django.utils.functional.__proxy__ object at 0x10906b3d0>, u'invalid': <django.utils.functional.__proxy__ object at 0x1090e3e50>, u'invalid_choice': <django.utils.functional.__proxy__ object at 0x10906b1d0>, u'blank': <django.utils.functional.__proxy__ object at 0x10906b390>, u'null': <django.utils.functional.__proxy__ object at 0x10906b350>, u'unique_for_date': <django.utils.functional.__proxy__ object at 0x10906b410>}, '_error_messages': None, 'db_constraint': True, '_verbose_name': u'main image thumbnail', 'name': u'main_image_thumbnail', 'db_column': None, 'default': <class django.db.models.fields.NOT_PROVIDED at 0x1090592c0>, 'attname': u'main_image_thumbnail_id', 'column': u'main_image_thumbnail_id', 'model': <class 'Post'>, 'opts': <Options for Post>}
(Pdb)
I am wondering if this is happening here: https://github.com/divio/cmsplugin-filer/blob/develop/cmsplugin_filer_image/migrations/0001_initial.py#L72
@electroniceagle how does your project compare to this sample https://github.com/yakky/blog-demo, especially WRT requirements, django version etc
Unless I'm missing it, I don't see any major differences. I'll try the demo config and look at settings...
@yakky I had to float a few unrelated app versions to get pip to install, but looks like this worked (column and googlemap have issues, but not the problem we're fixing). I've recreated my virtualenv multiple times, but was able to recreate having djangocms-blog 0.8.5 installed via pip and 0.8.7 installed via ./manage.py develop. I'm going to go nuke my original virtualenv for the 100th time and make sure I purge pip versions before testing my large pile of apps. Thanks for the sanity check demo.
[blog-demo] bschott@ironman-2 ~/Source/blog-demo (master)
$ pip freeze
aldryn-apphooks-config==0.2.7
aldryn-boilerplates==0.7.4
aldryn-common==1.0.4
aldryn-search==0.2.12
cmsplugin-filer==1.1.3rc1
dj-database-url==0.4.1
Django==1.8.14
django-appconf==1.0.2
django-appdata==0.1.5
django-classy-tags==0.8.0
django-cms==3.3.2
django-filer==1.2.4
django-formtools==1.0
django-haystack==2.5.0
django-meta==1.3.1
django-meta-mixin==0.3.0
django-mptt==0.8.6
django-parler==1.6.5
django-polymorphic==0.8.1
django-reversion==1.10.2
django-sekizai==0.10.0
Django-Select2==4.3.2
django-sortedm2m==1.3.2
django-spurl==0.6.4
django-standard-form==1.1.1
django-taggit==0.21.2
django-taggit-autosuggest==0.3.0
django-taggit-templatetags==0.2.5
django-templatetag-sugar==1.0
django-treebeard==4.0.1
djangocms-admin-style==1.2.3
djangocms-apphook-setup==0.1.2
djangocms-attributes-field==0.1.1
-e git+git@github.com:nephila/djangocms-blog.git@ab7929648effd815b2d56eaef51d54fe1107ff15#egg=djangocms_blog
djangocms-column==1.6.0
djangocms-googlemap==0.5.1
djangocms-installer==0.9rc3
djangocms-link==1.8.2
djangocms-snippet==1.8.2
djangocms-style==1.7.0
djangocms-text-ckeditor==3.1.0
djangocms-video==1.1.0
easy-thumbnails==2.3
html5lib==0.9999999
lxml==3.6.4
Pillow==3.3.1
pytz==2016.6.1
six==1.10.0
tzlocal==1.2.2
Unidecode==0.4.19
URLObject==2.4.2
YURL==0.13
[blog-demo] bschott@ironman-2 ~/Source/blog-demo (master)
$ ./manage.py makemigrations --dry-run
Migrations for 'djangocms_column':
0002_auto_20160901_2259.py:
- Alter field cmsplugin_ptr on column
- Alter field cmsplugin_ptr on multicolumns
Migrations for 'djangocms_googlemap':
0003_auto_20160901_2259.py:
- Alter field style on googlemap
I can confirm that hotfix/thumbnail_model fixed the issue. Thanks! Close when merged?
@electroniceagle thanks, merging now and releasing 0.8.8 soon! Thanks for reporting and testing
We have a make migrations dry run test that is failing because of the ThumbnailOption move. I think the issue is that some of the migration steps refer to cmsplugin_filer_image.ThumbnailOption and others expect cmsplugin_filer.ThumbnailOption when parsing all of the historical migrations files. I'm not sure if we'll have to do some conditional magic in the old migrations. Investigating now.
Note, migrate passes just fine.