First of all, thanks for all the feedback!
While the PR is in a good state there's one discussion happening with a
decision that needs to be made:
The current Django documentation states that log messages are send to the
console from INFO level an up. However, because of a misconfiguration this
is not true; messages are logged for WARNING and above
(see https://github.com/django/django/pull/5289 for a patch for that, see
discussion at
https://groups.google.com/forum/#!topic/django-developers/no2IhnRty68).
Giving the updated default configuration, sending log messages to any
logger in the `django` namespace ('django.*') will show up on the command
line when run on DEBUG=True. This may make sense for `django.request` as
that is issued from the runserver command, but at least the newly
introduced `django.db.migrations` logger is not too helpful on the console.
Even for `django.db` (query logging) I'm not too happy for it to show up in
`manage.py shell` but like it in `manage.py runserver`.
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,
while option 2 is currently implemented but comes with the disadvantage
that you can't separate the two log levels. Option 3 works too, but could
cause some weird behavior and confusion if not documented why it's set.
Option 4, no idea, it sounds correct to me.
/Markus
On Sunday, September 13, 2015 at 10:08:15 AM UTC+10, Markus Holtermann
wrote:
>
> Hey there,
>
> here's a pull request for this feature:
> https://github.com/django/django/pull/5279 . I'd appreciate some review.
>
> /Markus
>
> On Wednesday, May 20, 2015 at 9:25:00 AM UTC+10, steve byerly wrote:
>>
>> Awesome, thank you very much for the detailed answer.
>> -Steve
>>
>> On Tue, May 19, 2015 at 4:16 PM, Shai Berger wrote:
>>
>>> Hi Steve,
>>>
>>> On Wednesday 20 May 2015 01:50:15 steve byerly wrote:
>>> >
>>> > I'm also unclear what the argument against storing in the migrations
>>> table
>>> > is vs logging them - honest question. Since I have 4 web servers, the
>>> > information would be logged to any one of them - depending on which
>>> > executed the migration during deploy.
>>> >
>>>
>>> The argument is, basically, that logging solves a more general use-case,
>>> and
>>> so it is a better solution for the problem.
>>>
>>> Your use case, as you described it:
>>>
>>> > During a deploy, it's really nice to make sure you faked the right
>>> > migrations/didn't fake the wrong migrations
>>>
>>> fits in the general pattern of "I want to know what happened in this
>>> system".
>>> Logging, as far as we understand, solves that problem. The migrations
>>> table
>>> solves a different problem -- it records which migrations the system
>>> considers
>>> to have been executed, to support the decision of which migrations to run
>>> (when asked to). One of the outstanding "conflicts" between the two
>>> goals is
>>> encountered when a migration is rolled back: For "decision support", the
>>> simplest handling is to delete the migration's record from the table
>>> (and this
>>> is what Django does, AFAIK). For "forensics", this behavior is quite
>>> unacceptable.
>>>
>>> The most natural solution for knowing what happened in a system is
>>> logging.
>>> When you have 4 servers, you want some federated logging anyway --
>>> migrations
>>> are probably not the only case where something that happens on one server
>>> affects the behavior of others. Be that as it may, Python's logging
>>> library
>>> allows you to set different handlers for different loggers -- so,
>>> assuming
>>> migrations get their own logger, it shouldn't be very hard to set up
>>> logging
>>> so that all migration logging goes to some special place. That place can
>>> even
>>> be the database -- see e.g. https://pypi.python.org/pypi/django-logdb
>>> (I have
>>> no personal experience with that package, I just searched for it).
>>>
>>> HTH,
>>> Shai.
>>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/e9fda94e-f405-472d-bb08-f099e
