I created ticket for this: https://code.djangoproject.com/ticket/24203
On Friday, December 26, 2014 at 9:54:52 PM UTC+1, Collin Anderson wrote:
>
> Ohh, I see. Yes, this looks like a possible spot for optimization. I
> wouldn't really call it a "bug", but a "cleanup/optimization". You could
> pr
Ohh, I see. Yes, this looks like a possible spot for optimization. I
wouldn't really call it a "bug", but a "cleanup/optimization". You could
probably open a ticket about it.
On Tuesday, December 23, 2014 5:04:55 AM UTC-6, pjotr wrote:
>
> Sorry, all the ALTER statements are identical except the
Sorry, all the ALTER statements are identical except the FIELDNAME. It adds
6 new fields.
On Tuesday, December 23, 2014 4:46:42 AM UTC+1, Collin Anderson wrote:
>
> Hi,
>
> You're just using one database?
>
> Are all 6 ALTER statements identical?
>
> Collin
>
> On Sunday, December 21, 2014 5:27:0
Hi,
You're just using one database?
Are all 6 ALTER statements identical?
Collin
On Sunday, December 21, 2014 5:27:06 PM UTC-6, pjotr wrote:
>
> Just realized the subject was wrong, it should be *makemigrations , not
> makemigrate*
>
> On Sunday, December 21, 2014 8:36:29 PM UTC+1, pjotr wrote
Just realized the subject was wrong, it should be *makemigrations , not
makemigrate*
On Sunday, December 21, 2014 8:36:29 PM UTC+1, pjotr wrote:
>
> Hi,
>
> I have a django model that I just added six new fields to. I ran
> *makemigrations
> *and after that noticed when we ran our rehearsal upg
Hi,
I have a django model that I just added six new fields to. I ran
*makemigrations
*and after that noticed when we ran our rehearsal upgrade with dump of the
production database that things took longer than we expected, and checked
the processlist. We saw that there were six *alter table* st
6 matches
Mail list logo
