Django 1.8 requires a connection to the 'postgres' database in order to
resolve ticket #16969 [1]. We've had several reports of cases where
connecting to the 'postgres' database isn't permitted (e.g. Heroku and
other shared hosting providers) which causes problems when running tests
and in some
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
1. I don't see much benefit to adding a max length for one form
(AuthenticationForm) to give some sense of security as opposed to properly
addressing the issue at the webserver level. As Paul said, "As documented
in the deployment docs, it is your responsibility as the deployer to limit
post bo
I don't know of any tickets or plans to address this.
On Wednesday, May 13, 2015 at 12:51:59 AM UTC-4, Pradeek J wrote:
>
> I'm facing the same speed issue here. Like Andrew mentioned above, if
> initial data is going to be removed and data migrations are the way
> forward, even having an option
10 matches
Mail list logo
