Just on this point:
> I agree with Andrew Godwins statement on Django loosing many contributors
over the years and being in largely maintenance mode.
First, I'm not sure Andrew actually said this. Rather I think he reported
is a point raised. However...
I hear this kind of thing said. It
I'm inclined towards "separate thing all together". Maybe they're all
related but the bigger a ticket gets the less chance it has of actually
> ... DB credentials...
Let's say you put those in environment variables... Don't you just relaunch
with a new environment to
This should be a separate ticket.
I'm not sure what you need for DB credential rotation - this can already be
done by creating a second user in your database, then changing Django's
config to use the new one, then deleting the old one.
On Thu, 8 Aug 2019 at 02:43, John Gooding wrote:
I have also come across the need for this and would be willing to work on a
pull request for this feature.
On Wednesday, August 7, 2019 at 3:43:43 AM UTC+2, bjw wrote:
> At present the admin autocomplete docs mention
> `ModelAdmin.autocomplete_fields` and
> `ModelAdmin.search_fields` which
Although I'm not engaged too much with Django development now, a big
drawback of moving to GitHub issues for me would be that I could no longer
do a Google search like "something something site:code.djangoproject.com".
I could pretty much always find the ticket I was looking for that way.
I think the way Rails does it, aka with well-done newcomers guide
worth looking at, as Carlton notes. A bit more streamlined than the current
Django How To Contribute Guides.
Incidentally, Carlton and I will be having a
Actually you can refer to one to many relation model.
Its like one user has multiple address
One adress has multiple users.
In models file.
You can make changes.
For 1 user multiple address
Hi, I'm developing app with django. I have users module. My database schema
users table and address table. Address table have foreign key from users
table. Now how can compose app architecture? Should i new module as address
and i should put address model etc. or Should i write address table in
So regarding the implementation my proposal is this:
instead of checking if a prefixed url pattern exists, resolve the current
request path to a pattern and check if it is i18n prefixed
any idea how much of a performance hit that would be? Because right now
we're accessing a cached variable,
On Wednesday, August 7, 2019 at 9:22:27 PM UTC-5, Markus Holtermann wrote:
> Let's look at the last question first, regarding duplicate entries in the
> django_migrations table: Yes, this is to be a bug. At least how it's
> currently used.
> Let's say you have migration
On Monday, August 5, 2019 at 4:55:24 PM UTC-5, Barry Johnson wrote:
> [ TL;DR: A migration may use a “replaces” list pointing to migrations that
> don’t actually exist. This undocumented technique cleanly solves a
> recurring difficult migration problem. We seek consensus on whether this
On Wednesday, August 7, 2019 at 2:17:45 PM UTC-5, Adam Johnson wrote:
> Some questions: Have you looked into the migration framework internals?
> Are there any comments around "replaces" that indicate this behaviour? And
> is there maybe a way of hooking into the migration planner, or adding
I have had a short reply sitting in draft status for a while but not found
the energy to read all of your posts.
I'd just like to chime in and echo the sentiment from Aymeric, Florian,
Luke, and Tim. I worked with Django for nearly 5 years before being
accepted onto the core team.
Mail list logo