sorry for the unspecific summary, but I expect to have a few issues here
without knowing how to tell on from the other.
I expect squashmigrations with optimization turned on (default) to result
in a squashed migration file so that running makemigration afterwards
doesn't detect any migration needs. In my case though, some single
migrations doesn't seem to to be in the squashed migration file.
Squashing is important to me, because for some time I temporarily
experimented with third-party libraries I don't want to include anymore.
But installing/migrating in a new database still require them to be in the
virtual environment, of cource, if not squashed mit optimization on.
See attachments:
* Zip of single migrations 0001 to 0116
* Resulting squashed migration file of "manage.py squashmigrations
knowledgebase 0116"
* Resulting migration file of "manage.py makemigrations"
Additionally, I found that two models seem to have disappeared completely
in the squashed migration file as well as it has not been recognized by
the makemigrations cross-check:
* AbstractEntity - this may be ok since it's an abstract super-class, but
note that AbtractCategory *is* included in the squashing
* Activity - this model vanished
See attachment models.py
--
Ticket URL: <https://code.djangoproject.com/ticket/34924>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* Attachment "single_migrations.zip" added.
* Attachment
"0001_squashed_0116_impact_alternative_names_alter_document_assocs_and_more.py"
* Attachment
"0117_alter_actor_category_alter_document_abstract_and_more.py" added.
* Attachment "models.py" added.
Old description:
> Hi there,
>
> sorry for the unspecific summary, but I expect to have a few issues here
> without knowing how to tell on from the other.
>
> I expect squashmigrations with optimization turned on (default) to result
> in a squashed migration file so that running makemigration afterwards
> doesn't detect any migration needs. In my case though, some single
> migrations doesn't seem to to be in the squashed migration file.
>
> Squashing is important to me, because for some time I temporarily
> experimented with third-party libraries I don't want to include anymore.
> But installing/migrating in a new database still require them to be in
> the virtual environment, of cource, if not squashed mit optimization on.
>
> See attachments:
> * Zip of single migrations 0001 to 0116
> * Resulting squashed migration file of "manage.py squashmigrations
> knowledgebase 0116"
> * Resulting migration file of "manage.py makemigrations"
>
> Additionally, I found that two models seem to have disappeared completely
> in the squashed migration file as well as it has not been recognized by
> the makemigrations cross-check:
> * AbstractEntity - this may be ok since it's an abstract super-class, but
> note that AbtractCategory *is* included in the squashing
> * Activity - this model vanished
>
> See attachment models.py
New description:
Hi there,
sorry for the unspecific summary, but I expect to have a few issues here
without knowing how to tell on from the other.
I expect squashmigrations with optimization turned on (default) to result
in a squashed migration file so that running makemigration afterwards
doesn't detect any migration needs. In my case though, some single
migrations doesn't seem to to be in the squashed migration file.
Squashing is important to me, because for some time I temporarily
experimented with third-party libraries I don't want to include anymore.
But installing/migrating in a new database still require them to be in the
virtual environment, of cource, if not squashed mit optimization on.
See attachments:
* Zip of single migrations 0001 to 0116
* Resulting squashed migration file of "manage.py squashmigrations
knowledgebase 0116"
* Resulting migration file of "manage.py makemigrations" -> 0117
Additionally, I found that two models seem to have disappeared completely
in the squashed migration file as well as it has not been recognized by
the makemigrations cross-check:
* AbstractEntity - this may be ok since it's an abstract super-class, but
note that AbtractCategory *is* included in the squashing
* Activity - this model vanished
See attachment models.py
--
--
Ticket URL: <https://code.djangoproject.com/ticket/34924#comment:1>
Old description:
> * Resulting migration file of "manage.py makemigrations" -> 0117
>
> Additionally, I found that two models seem to have disappeared completely
> in the squashed migration file as well as it has not been recognized by
> the makemigrations cross-check:
> * AbstractEntity - this may be ok since it's an abstract super-class, but
> note that AbtractCategory *is* included in the squashing
> * Activity - this model vanished
>
> See attachment models.py
New description:
Hi there,
sorry for the unspecific summary, but I expect to have a few issues here
without knowing how to tell one from the other.
I expect squashmigrations with optimization turned on (default) to result
in a squashed migration file so that running makemigration afterwards
doesn't detect any migration needs. In my case though, makemigration
detected for differences, i.e. some single migrations doesn't seem to be
in the squashed migration file.
Squashing is important to me, because for some time I temporarily
experimented with third-party libraries I don't want to include anymore.
But installing/migrating in a new database still require them to be in the
virtual environment, of course, if not squashed with optimization on.
See attachments:
* Zip of single migrations 0001 to 0116
* Resulting squashed migration file of "manage.py squashmigrations
knowledgebase 0116"
* Resulting migration file of "manage.py makemigrations" -> 0117
Additionally, I found that two models seem to have errorneously
disappeared completely in the squashed migration file as well as they have
not been recognized by the makemigrations cross-check (which I expected to
be empty anyway):
* Activity
* AbstractEntity - this may be ok since it's an abstract super-class, but
note that AbstractCategory *is* included in the squashing
See attachment models.py
In case any information is missing please don't hesitate to contact me.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/34924#comment:2>
* status: new => closed
* resolution: => duplicate
Comment:
Thanks for this report, it's a duplicate of #26223 (`document.created_at`,
`document.abstract`, `evidence.reference`) and #32263 (`actor.category`).
--
Ticket URL: <https://code.djangoproject.com/ticket/34924#comment:3>