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.
