Hi,
On Wednesday 16 September 2015 03:13:35 Markus Holtermann wrote:
>
> I see the following solutions to bring this PR forward:
>
> 1. Configure `django.db.migrations` logger to not send messages to
> console by default and keep log levels to INFO (for "Applied/Unapplied
> migration XYZ") and DEBUG (for "Marked migraiton XYZ as
> applied/unapplied")
> 2. Change the log levels for both messages to DEBUG
> 3. Don't propagate messages from `django.db.migrations` logger to
> parents
> 4. Don't go forward with the above mentioned patch amending the
> default log level
>
> I prefer option 1 and clearly document how people can activate the logger,
Wait -- so you mean "turn logger off by default"? I'd find that strongly
counter-intuitive.
> while option 2 is currently implemented but comes with the disadvantage
> that you can't separate the two log levels.
As I noted on the PR, its biggest disadvantage IMO is that all migration
logging is then done at "DEBUG" level, which undermines the purpose set forth
in this thread.
> Option 3 works too, but could cause some weird behavior and confusion if not
> documented why it's set.
Yes. Exactly as counter-intuituve as option 1
> Option 4, no idea, it sounds correct to me.
>
I agree that INFO logging should go out to the console when activated by a
management command.
Let's recap: The main problem is the doubling of messages on migrations, as
the migrations framework already prints to stdout when it runs migrations.
A possible solution, then, is to turn off these printings in favor of the
logging. Its big disadvantage, AFAICT, is that the custom printing of
migrations is far prettier than the default logging format.
Another possible solution is a variation on Option 2 -- change the log levels
on both messages to DEBUG, but only if settings.DEBUG is on. Where
settings.DEBUG is off, it is also more likely that the django loggers do not go
to the console.
Yet another solution is to make a finer definition of which loggers print to
console by default -- for example, define a "django2"[1] logger hierarchy, with
the migrations logger under it instead of under "django", where django2 does
not propagate to root and, by default, has no handlers.
Out of ideas,
Shai.
[1] Yes, I know. Not a very descriptive name. It's 2AM here, it's the best I
can do now. Good night.
