Trac ticket #33191 was recently closed as a “wontfix”, but Carlton encouraged
bringing the matter to this group. The actual issue is a small one, but it
seems that Django could do better than it is doing today with one small change,
and avoid the need for a counter-intuitive "x = x" statement a
On Friday, October 15, 2021 at 12:39:52 PM UTC-5 pyt...@ian.feete.org wrote:
> You set out a good case, it's much easier to understand the "why" here
than in the original ticket.
Yes. It was hard to compress the matter down small enough to reasonably
fit in a Trac entry, so skipped the vast ma
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
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.
>
Agreed.
> Let's say you have migration foo.0001
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
ourselves writing two layers of validation ("one simple,
the other more sophisticated")... that that makes things even more
complex. We do indeed use the model-level validations for single-field
validations... but we invoke those validations from our business logic at
the proper tim
osed warning, I could live
with that for a while.
baj
-
Barry Johnson
On Wednesday, January 11, 2023 at 6:55:25 AM UTC-6 tatari...@gmail.com
wrote:
> As described in https://code.djangoproject.com/ticket/34251, some
> database backends (incl. PostgreSQL) will produce non-dete
For those working on async code, I just opened a question on the Django
Internals Async forum regarding query sets with prefetches, which aren't
currently supported in the alpha build of 4.2. A solution seemed so
surprisingly easy, I'm wondering what the real experts in the area would
think.
