Re: Migration Questioner and String-Type Fields

in > > ALTER TABLE "example_mymodel" ADD COLUMN "name2" varchar(150) DEFAULT > '' NOT NULL; > ALTER TABLE "example_mymodel" ALTER COLUMN "name2" DROP DEFAULT; > > and the second in a noop. > > I'm tryi

Re: Migration Questioner and String-Type Fields

an empty string into the questioner if that's what you want. > If we remove the prompt, it's significantly more work (editing a migration > file or using RunPython) for a developer to set a non-empty value. > > On Friday, September 9, 2016 at 7:19:37 PM UTC-4, Jarek Glowacki wrote: >

Re: Migration Questioner and String-Type Fields

then a new column with a non-blank value means that all > existing objects won't pass form validation. Therefore, I don't see why a > prompt for a value isn't helpful. > > On Friday, September 9, 2016 at 6:42:02 AM UTC-4, Jarek Glowacki wrote: >> >> I made

Migration Questioner and String-Type Fields

I made a rant/ticket regarding the hidden usage of `blank` here: #27197 . In short, I don't think that `blank` should dictate whether or not the migration questioner runs. Building on this, I don't think it should run for for string-type fields

Referencing squashed migrations

Greetings, Django does not currently support designating unapplied squashed migrations as dependencies. This feels like bad behaviour, especially since `makemigrations` will reference a squashed migration by default if it has already been applied locally. I've made a ticket