Squashed migration showing unapplied in python3 but applied in python2

[Vaibhav lodha]

Hi Everyone, 
In my org, we are trying to migrate from python2 to python3 with the django 
version as 1.9.4, but stuck in one issue which is we have 2 migrations 
which squashed, when we apply them in python2, it shows applied and migrate 
doesn't re-run it but when we run migrate with python3, it keeps on 
applying them even if they are already applied. We even tried faking the 
migration, but under the hood it faked the migrations inside of squashed 
migration instead of squashed migration itself. Do we have any idea how to 
fix this?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7626b78e-b311-4aff-aaeb-7351188f1103n%40googlegroups.com.

Re: Squashed migration

[aRkadeFR]

Great.

Thanks for the feedback :)

On 06/15/2015 02:18 PM, Cherie Pun wrote:

Hi,

So the original problem was that I was running in the repo which 
didn't have the squashed migration. Django does know when to switch to 
the squashed migrations when you have both squashed and unsquashed 
migration files coexist in the folder.
As for the syntax error it was because python cannot import from 
modules that starts with numbers. Also, the idea was that we shouldn't 
use the migration files as modules to import code from, that's why the 
file name stayed as it was. Users should manually move their RunPython 
methods manually and resolve those invalid references to migration files.


Hope this helps and sorry for confusing people that squash migration 
doesn't work! I am still new to Python and Django and I really 
appreciate everyone's replies.


Cheers,
Cherie

On Monday, June 15, 2015 at 9:54:09 AM UTC+1, aRkadeFR wrote:

Thanks for the good explanation as always :)

 From the documentation plus the explanation of the problem,
I wanted to know if by deleting the old migration it would still
run the old migrations.

Do we know the end of the story? Where it comes from?

Thanks

On 06/12/2015 05:42 PM, Carl Meyer wrote:
> On 06/12/2015 06:32 AM, aRkadeFR wrote:
>> You need to delete your old migrations so it uses only the
squashed
>> one after.
> No, the squashed migration should be used in place of the old
ones for
> any new database, even if the old ones are still present. This
is the
> point of the squashmigrations feature; that you can keep the old
ones
> around (which is necessary for any deployments that may not yet
have
> applied all of them) while still gaining the benefit of the new
squashed
> migration for new deployments (and tests).
>
> I know this works, because I just did it recently myself. It
sounds like
> Cherie was able to get it working too, though we didn't get any
> clarification on why it didn't seem to work originally.
>
>> In the documentation:
>> "This enables you to squash and not mess up systems currently in
>> production that aren’t fully up-to-date yet. The recommended
process is
>> to squash, keeping the old files, commit and release, wait
until all
>> systems are upgraded with the new release (or if you’re a
third-party
>> project, just ensure your users upgrade releases in order without
>> skipping any), and then remove the old files, commit and do a
second
>> release."
> That's right. The length of time you need to wait before
removing can
> vary widely. For a third-party app, it may be a full release
cycle or
> two (as long as you can tell your users to upgrade
version-by-version).
> For a project with only a few deployments, all under your
control, it
> may be the same day. But regardless, the squashed migration will
still
> be used in tests immediately, before you remove the old migrations.
>
> Carl
>

-- 
aRkadeFR


--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-users+unsubscr...@googlegroups.com 
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com 
<mailto:django-users@googlegroups.com>.

Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a46519d9-3819-40d5-8a18-236a4bec846e%40googlegroups.com 
<https://groups.google.com/d/msgid/django-users/a46519d9-3819-40d5-8a18-236a4bec846e%40googlegroups.com?utm_medium=email_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
aRkadeFR

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/557EC915.4020408%40arkade.info.
For more options, visit https://groups.google.com/d/optout.

Re: Squashed migration

[Cherie Pun]

Hi,

So the original problem was that I was running in the repo which didn't 
have the squashed migration. Django does know when to switch to the 
squashed migrations when you have both squashed and unsquashed migration 
files coexist in the folder.
As for the syntax error it was because python cannot import from modules 
that starts with numbers. Also, the idea was that we shouldn't use the 
migration files as modules to import code from, that's why the file name 
stayed as it was. Users should manually move their RunPython methods 
manually and resolve those invalid references to migration files.

Hope this helps and sorry for confusing people that squash migration 
doesn't work! I am still new to Python and Django and I really appreciate 
everyone's replies.

Cheers,
Cherie

On Monday, June 15, 2015 at 9:54:09 AM UTC+1, aRkadeFR wrote:
>
> Thanks for the good explanation as always :) 
>
>  From the documentation plus the explanation of the problem, 
> I wanted to know if by deleting the old migration it would still 
> run the old migrations. 
>
> Do we know the end of the story? Where it comes from? 
>
> Thanks 
>
> On 06/12/2015 05:42 PM, Carl Meyer wrote: 
> > On 06/12/2015 06:32 AM, aRkadeFR wrote: 
> >> You need to delete your old migrations so it uses only the squashed 
> >> one after. 
> > No, the squashed migration should be used in place of the old ones for 
> > any new database, even if the old ones are still present. This is the 
> > point of the squashmigrations feature; that you can keep the old ones 
> > around (which is necessary for any deployments that may not yet have 
> > applied all of them) while still gaining the benefit of the new squashed 
> > migration for new deployments (and tests). 
> > 
> > I know this works, because I just did it recently myself. It sounds like 
> > Cherie was able to get it working too, though we didn't get any 
> > clarification on why it didn't seem to work originally. 
> > 
> >> In the documentation: 
> >> "This enables you to squash and not mess up systems currently in 
> >> production that aren’t fully up-to-date yet. The recommended process is 
> >> to squash, keeping the old files, commit and release, wait until all 
> >> systems are upgraded with the new release (or if you’re a third-party 
> >> project, just ensure your users upgrade releases in order without 
> >> skipping any), and then remove the old files, commit and do a second 
> >> release." 
> > That's right. The length of time you need to wait before removing can 
> > vary widely. For a third-party app, it may be a full release cycle or 
> > two (as long as you can tell your users to upgrade version-by-version). 
> > For a project with only a few deployments, all under your control, it 
> > may be the same day. But regardless, the squashed migration will still 
> > be used in tests immediately, before you remove the old migrations. 
> > 
> > Carl 
> > 
>
> -- 
> aRkadeFR 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a46519d9-3819-40d5-8a18-236a4bec846e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Squashed migration

[aRkadeFR]

Thanks for the good explanation as always :)

From the documentation plus the explanation of the problem,
I wanted to know if by deleting the old migration it would still
run the old migrations.

Do we know the end of the story? Where it comes from?

Thanks

On 06/12/2015 05:42 PM, Carl Meyer wrote:

On 06/12/2015 06:32 AM, aRkadeFR wrote:

You need to delete your old migrations so it uses only the squashed
one after.

No, the squashed migration should be used in place of the old ones for
any new database, even if the old ones are still present. This is the
point of the squashmigrations feature; that you can keep the old ones
around (which is necessary for any deployments that may not yet have
applied all of them) while still gaining the benefit of the new squashed
migration for new deployments (and tests).

I know this works, because I just did it recently myself. It sounds like
Cherie was able to get it working too, though we didn't get any
clarification on why it didn't seem to work originally.


In the documentation:
"This enables you to squash and not mess up systems currently in
production that aren’t fully up-to-date yet. The recommended process is
to squash, keeping the old files, commit and release, wait until all
systems are upgraded with the new release (or if you’re a third-party
project, just ensure your users upgrade releases in order without
skipping any), and then remove the old files, commit and do a second
release."

That's right. The length of time you need to wait before removing can
vary widely. For a third-party app, it may be a full release cycle or
two (as long as you can tell your users to upgrade version-by-version).
For a project with only a few deployments, all under your control, it
may be the same day. But regardless, the squashed migration will still
be used in tests immediately, before you remove the old migrations.

Carl



--
aRkadeFR

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/557E9228.5080504%40arkade.info.
For more options, visit https://groups.google.com/d/optout.

Re: Squashed migration

[Carl Meyer]

Hi Cherie,

On 06/12/2015 06:32 AM, Cherie Pun wrote:
> Thanks for your replies! I am still on Django 1.7 but we are hoping to
> upgrade to 1.8 soon. I manage to use the squashed migrations when
> creating the test database now,

Do you know why it didn't work initially? That'd be useful to know, in
case it's something that might trip up other users, too.

> but there's syntax error in the
> automatically generated squash migration. The error occurs on the line
> on which it reference the user-defined functions in other migrations. It
> seems fine when it ran the first methods though.

That sounds like a probably-fixable bug (though it may already be fixed
in 1.8 and/or master). If you're able to reproduce the bug on master,
please do file a ticket for it.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/557AFE4C.7060403%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Squashed migration

[Carl Meyer]

On 06/12/2015 06:32 AM, aRkadeFR wrote:
> You need to delete your old migrations so it uses only the squashed
> one after.

No, the squashed migration should be used in place of the old ones for
any new database, even if the old ones are still present. This is the
point of the squashmigrations feature; that you can keep the old ones
around (which is necessary for any deployments that may not yet have
applied all of them) while still gaining the benefit of the new squashed
migration for new deployments (and tests).

I know this works, because I just did it recently myself. It sounds like
Cherie was able to get it working too, though we didn't get any
clarification on why it didn't seem to work originally.

> In the documentation:
> "This enables you to squash and not mess up systems currently in
> production that aren’t fully up-to-date yet. The recommended process is
> to squash, keeping the old files, commit and release, wait until all
> systems are upgraded with the new release (or if you’re a third-party
> project, just ensure your users upgrade releases in order without
> skipping any), and then remove the old files, commit and do a second
> release."

That's right. The length of time you need to wait before removing can
vary widely. For a third-party app, it may be a full release cycle or
two (as long as you can tell your users to upgrade version-by-version).
For a project with only a few deployments, all under your control, it
may be the same day. But regardless, the squashed migration will still
be used in tests immediately, before you remove the old migrations.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/557AFDF3.1090900%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Squashed migration

[aRkadeFR]

Hey,

You need to delete your old migrations so it uses only the squashed
one after.

In the documentation:
"This enables you to squash and not mess up systems currently in 
production that aren’t fully up-to-date yet. The recommended process is 
to squash, keeping the old files, commit and release, wait until all 
systems are upgraded with the new release (or if you’re a third-party 
project, just ensure your users upgrade releases in order without 
skipping any), and then remove the old files, commit and do a second 
release."


https://docs.djangoproject.com/en/1.8/topics/migrations/#squashing-migrations

On 06/12/2015 11:38 AM, Cherie Pun wrote:

Hi,

I have trying to experiment with squashmigration to see if it will 
make it faster to build the database when running tests. So I have 
squashed the migrations following the instructions on the Django 
website. However when I run the tests, it still uses the original 
migrations. I thought Django automatically uses the squashed one over 
the separated ones. Is there some settings that I have to configure? 
Also, it says that no optimisation was available even though there are 
a few AddField which should in theory be combined into AddModel.


Any help or suggestions will be much appreciated, thanks!

Cherie
--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-users@googlegroups.com 
.

Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9288958d-0214-4cd2-9b51-dd173a8e83ae%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
aRkadeFR

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/557AD178.9090707%40arkade.info.
For more options, visit https://groups.google.com/d/optout.

Re: Squashed migration

[Cherie Pun]

Hi,

Thanks for your replies! I am still on Django 1.7 but we are hoping to 
upgrade to 1.8 soon. I manage to use the squashed migrations when creating 
the test database now, but there's syntax error in the automatically 
generated squash migration. The error occurs on the line on which it 
reference the user-defined functions in other migrations. It seems fine 
when it ran the first methods though.

Cheers, 
Cherie

On Friday, June 12, 2015 at 12:17:38 PM UTC+1, Filipe Ximenes wrote:
>
> Hi Cherie, maybe you can run your tests without the migrations. This 
> django app may solve your problem: 
> https://github.com/henriquebastos/django-test-without-migrations/
>
> On Fri, Jun 12, 2015 at 6:38 AM, Cherie Pun  > wrote:
>
>> Hi,
>>
>> I have trying to experiment with squashmigration to see if it will make 
>> it faster to build the database when running tests. So I have squashed the 
>> migrations following the instructions on the Django website. However when I 
>> run the tests, it still uses the original migrations. I thought Django 
>> automatically uses the squashed one over the separated ones. Is there some 
>> settings that I have to configure? Also, it says that no optimisation was 
>> available even though there are a few AddField which should in theory be 
>> combined into AddModel.
>>
>> Any help or suggestions will be much appreciated, thanks!
>>
>> Cherie
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/9288958d-0214-4cd2-9b51-dd173a8e83ae%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>   
>
> *Filipe Ximenes*+55 (81) 8245-9204
>
> *Vinta Software Studio*http://www.vinta.com.br
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d997ffc2-b35e-4587-a278-cb2176f2cff5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Squashed migration

[Filipe Ximenes]

Hi Cherie, maybe you can run your tests without the migrations. This django
app may solve your problem:
https://github.com/henriquebastos/django-test-without-migrations/

On Fri, Jun 12, 2015 at 6:38 AM, Cherie Pun  wrote:

> Hi,
>
> I have trying to experiment with squashmigration to see if it will make it
> faster to build the database when running tests. So I have squashed the
> migrations following the instructions on the Django website. However when I
> run the tests, it still uses the original migrations. I thought Django
> automatically uses the squashed one over the separated ones. Is there some
> settings that I have to configure? Also, it says that no optimisation was
> available even though there are a few AddField which should in theory be
> combined into AddModel.
>
> Any help or suggestions will be much appreciated, thanks!
>
> Cherie
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/9288958d-0214-4cd2-9b51-dd173a8e83ae%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Filipe Ximenes*+55 (81) 8245-9204

*Vinta Software Studio*http://www.vinta.com.br

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAA-QWB2LMVvigsNXfo3bRfidTAd%3DmgctQ9Trmm4tO%2BqMGfdi%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Squashed migration

[Erik Cederstrand]

> Den 12/06/2015 kl. 11.38 skrev Cherie Pun  >:
> 
> Hi,
> 
> I have trying to experiment with squashmigration to see if it will make it 
> faster to build the database when running tests. So I have squashed the 
> migrations following the instructions on the Django website. However when I 
> run the tests, it still uses the original migrations. I thought Django 
> automatically uses the squashed one over the separated ones. Is there some 
> settings that I have to configure? Also, it says that no optimisation was 
> available even though there are a few AddField which should in theory be 
> combined into AddModel.

squashmigrations has limits to what it can do. You are free to edit the 
migration by hand if you can spot any more optimizations, and file a bug report 
if you spot something that the squasher should reasonably detect.

Have you seen the new "manage.py test --keepdb" in Django 1.8? I have a 
complicated project with lots of apps and use it daily to speed up testing. 
https://docs.djangoproject.com/en/1.8/ref/django-admin/#test-app-or-test-identifier
 


Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5968C3C9-1515-4B61-9E9C-964EC60B030E%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Squashed migration

[Cherie Pun]

Hi,

I have trying to experiment with squashmigration to see if it will make it 
faster to build the database when running tests. So I have squashed the 
migrations following the instructions on the Django website. However when I 
run the tests, it still uses the original migrations. I thought Django 
automatically uses the squashed one over the separated ones. Is there some 
settings that I have to configure? Also, it says that no optimisation was 
available even though there are a few AddField which should in theory be 
combined into AddModel.

Any help or suggestions will be much appreciated, thanks!

Cherie

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9288958d-0214-4cd2-9b51-dd173a8e83ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Slowness of the resulting squashed migration

[aRkadeFR]

Thanks for the answer.

Right now, I just know that after squashing some migrations,
it created a squashed migrations with CreateModel + AlterField
and AddField after that runs on 5seconds, and now that I put
all the field in the CreateModel without any AlterField or AddField,
it runs on <2secondes.

I had some custom RunPython function in the migrations but
removed it for the squashing.

I will dig a bit more and open a ticket if I can reproduce it :)

Have a good day

On 04/24/2015 09:09 PM, Markus Holtermann wrote:

Hi,

In principle it is possible to write your own or modify existing 
migrations unless they are already applied.


Regarding the additional AddField() operations: in case you have e.g. 
circular references between two models Django cannot add both models 
with their full columns at the same time. Django first adds one model 
without the ForeignKey, then the second model including the FK to the 
first model and finally adds the field to the first model pointing to 
the second model [1]. Bottom line: if you find a way to optimize 
something in your squashed migration, feel free to go ahead. It would 
be helpful if you report this as an enhance to our issue tracker [2] 
so we can include a possible improvement in future Django versions.


/Markus

[1] Have a look at slide 14f 
of https://speakerdeck.com/andrewgodwin/migrations-under-the-hood

[2] https://code.djangoproject.com/

On Friday, April 24, 2015 at 8:14:34 PM UTC+2, aRkadeFR wrote:

Hello,

After working on a project and having around 10 migrations per app,
I wanted to refactor some migrations (of the same app) into only one
and have a faster migrations while testing.

I did squashmigrations on many of the migrations, but the resulting
squased migration is still pretty slow (around 6 seconds to create 4
tables on MySQL 5.5 without any data inserted).

After looking at the migrations, there is some
CreateModel(name='')
and after the table creation some AddField on the same
table/models...

I would like to know if it's safe to change the migrations by
hand? Is
there a reason the squashmigrations didn't refactor into only
CreateModel
without AddField then?

Thanks

aRkadeFR



--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/553E0EFE.60902%40arkade.info.
For more options, visit https://groups.google.com/d/optout.

Re: Slowness of the resulting squashed migration

[Markus Holtermann]

Hi,

In principle it is possible to write your own or modify existing migrations 
unless they are already applied.

Regarding the additional AddField() operations: in case you have e.g. 
circular references between two models Django cannot add both models with 
their full columns at the same time. Django first adds one model without 
the ForeignKey, then the second model including the FK to the first model 
and finally adds the field to the first model pointing to the second model 
[1]. Bottom line: if you find a way to optimize something in your squashed 
migration, feel free to go ahead. It would be helpful if you report this as 
an enhance to our issue tracker [2] so we can include a possible 
improvement in future Django versions.

/Markus

[1] Have a look at slide 14f 
of https://speakerdeck.com/andrewgodwin/migrations-under-the-hood
[2] https://code.djangoproject.com/

On Friday, April 24, 2015 at 8:14:34 PM UTC+2, aRkadeFR wrote:
>
> Hello, 
>
> After working on a project and having around 10 migrations per app, 
> I wanted to refactor some migrations (of the same app) into only one 
> and have a faster migrations while testing. 
>
> I did squashmigrations on many of the migrations, but the resulting 
> squased migration is still pretty slow (around 6 seconds to create 4 
> tables on MySQL 5.5 without any data inserted). 
>
> After looking at the migrations, there is some CreateModel(name='') 
> and after the table creation some AddField on the same table/models... 
>
> I would like to know if it's safe to change the migrations by hand? Is 
> there a reason the squashmigrations didn't refactor into only CreateModel 
> without AddField then? 
>
> Thanks 
>
> aRkadeFR 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c75633dd-b41a-46af-9e72-ced31e2e6885%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Slowness of the resulting squashed migration

[aRkadeFR]

Hello,

After working on a project and having around 10 migrations per app,
I wanted to refactor some migrations (of the same app) into only one
and have a faster migrations while testing.

I did squashmigrations on many of the migrations, but the resulting
squased migration is still pretty slow (around 6 seconds to create 4
tables on MySQL 5.5 without any data inserted).

After looking at the migrations, there is some CreateModel(name='')
and after the table creation some AddField on the same table/models...

I would like to know if it's safe to change the migrations by hand? Is
there a reason the squashmigrations didn't refactor into only CreateModel
without AddField then?

Thanks

aRkadeFR

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/553A87EB.9080506%40arkade.info.
For more options, visit https://groups.google.com/d/optout.