Maybe we could have BaseCommand remove the 'console' handler from the
'django' logger during the command's execution (at least under normal
verbosity conditions)?
As mentioned on the pull request, there is also an idea to update
management commands to use logging [1]. I think the two ideas coul
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 XY
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
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 a
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 - hon
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 t
Sorry all, i didn't get notified of the replies.
I guess I assumed that since you are already capturing the applied
migrations in the database, why not also capture if it was faked or not?
In the case I outlined in the original post, there were initial migrations
(0001, 0002, 0003) and new mig
I think having the Python logging module outputting the things the
migrations framework does, seems to be a good idea. I can see some use
cases where people want to turn that on.
I opened an issue to keep track of the feature
request: https://code.djangoproject.com/ticket/24800
/Markus
On Thu
I agree a log would be helpful, but I'm not sure that should be stored in
the database? We could either add a history/audit table in the database or
we could have some way of configuring a logger that stores locally (which
is a much higher bar, but presumably where sysadmins actually want logs?)
A
I think we had this discussion, more-or-less, around South migrations (I
looked a little, but couldn't find it). The context there was, as Tim hinted,
"forensics" -- trying to figure out how a system came into its (broken) state.
For that (as well as the OP's case, AFAICT) it makes little sense
I agree with Markus/Tim - the whole point of faked migrations is that
they're meant to exactly match the existing schema. If Django is
auto-faking migrations that don't match the existing one that would be a
bug, but it's almost too conservative in that aspect.
Are you manually faking these migrat
Hi Steve,
apart from what Tim said, since you commit the migration files as part
of the apps' code to your source code version control system, you can
simply have a look at the commit dates there. I'm not convinced having a
marker for faked migrations in the database is useful.
/Markus
On Wed,
I'm curious to know the reason why it would be helpful to know whether or
not a migration was faked. When you fake a migration, you are promising
that your schema matches the migration, so it seems to me that it would
only matter if you made a mistake there.
On Wednesday, May 13, 2015 at 12:38:
I couldn't find any related discussions on this topic, but I would find it
helpful to have documentation whether a specific migration was faked or
not. This would allow someone to look at all migrations that have been run
and see which ones were actually applied.
My use case is migrating a larg
14 matches
Mail list logo
