Try looking at the code in the autodetector and doing some some debugging
to figure out how old_field_dec and new_field_dec are different:
https://github.com/django/django/blob/8db6a6c0a1c73bf08e71e00d4ab8c4af3c5f0cb8/django/db/migrations/autodetector.py#L911
On Monday, December 12, 2016 at 5:58:
On 13/12/2016 9:58 AM, Francis Fisher wrote:
On Wednesday, 30 November 2016 22:43:55 UTC, Mike Dewhirst wrote:
On 1/12/2016 3:56 AM, Francis Fisher wrote:
> Any idea why makemigrations would fail to recognise that a
migration
> has already been generated?
I think migrations
On Wednesday, 30 November 2016 22:43:55 UTC, Mike Dewhirst wrote:
>
> On 1/12/2016 3:56 AM, Francis Fisher wrote:
> > Any idea why makemigrations would fail to recognise that a migration
> > has already been generated?
>
> I think migrations is seeing field choices differently each time it
> sc
I've seen that happening when calling a callable as one of the keyword
argument rather than passing the callable itself. Typical example:
class TimeFramedModel(models.Model):
created = models.DateTimeField(default=timezone.now*()*)
Instead of:
class TimeFramedModel(models.Model):
create
On 1/12/2016 3:56 AM, Francis Fisher wrote:
Any idea why makemigrations would fail to recognise that a migration
has already been generated?
I think migrations is seeing field choices differently each time it
scans the model. Can you use a list rather than a tuple for choices? (Or
vice versa
Any idea why makemigrations would fail to recognise that a migration has
already been generated?
makemigrations.py is a script which calls makemigrations with appropriate
django settings. If I run this once, it will generate the initial
migration, but every time I run it subsequently, it will r
6 matches
Mail list logo