Re: How to do a counter in DB cache class?

requests - ouch! > > An in-python counter, with a random offset per process (actually process > id *plus* thread id), could also work. But it would be trickier imo. > > Thanks, > > Adm > > On Tue, 1 Jun 2021 at 18:28, 'Mike Lissner' via Django developers > (Contributions

How to do a counter in DB cache class?

This might be more of a Python question than a Django one, but in this ticket I'm hoping to make the DB cache a bit more performant by having it not cull stale entries *every* time somebody adds, changes, or touches a cache key. The idea is to use

Re: Should there be a default lockfile location for SerializeMixin?

the check for the lockfile attribute to import time. > Then you don't need to go through a whole test run to find misconfigured > tests. I've made a PR for that here: > https://github.com/django/django/pull/14427 > > Thanks, > > Adam > > On Fri, 21 May 2021 at 01:36,

Should there be a default lockfile location for SerializeMixin?

I spent the day today making the tests for my project run in parallel. As part of that, I had my first encounter with the SerializeMixin, which you can use in conjunction with the `--parallel` flag to ensure that certain tests don't run at the same time. It's neat, in theory:

Re: Do people actually squash migrations?

Thanks for those links. I went ahead and filed a PR that describes a new "Migration Trimming" process. I'd love comments and suggestions if folks are interested and able: https://github.com/django/django/pull/14408 Mike On Mon, May 17, 2021 at 8:27 AM René Fleschenberg wrote: > Hi, > > I

Re: Do people actually squash migrations?

Oh, I guess there's also a step in the manual process to reset the migrations table in the DB, but I don't know how to do that. Tricky stuff! On Wednesday, May 12, 2021 at 9:37:53 AM UTC-7 Mike Lissner wrote: > So sort of sounds like an update to the squash migration docs is needed if > this

Re: Do people actually squash migrations?

So sort of sounds like an update to the squash migration docs is needed if this is representative of the general sentiment. Looking at the section on this , the general outline is: 1. Overview 2. How it works 3.

Do people actually squash migrations?

I have a pretty big django project, and since I created the 100th migration within one of its apps today, I thought I'd finally do some squashing. It hasn't gone well, but I eventually got the data migrations cleaned up. Finally, I run it, and it runs smack into a CircularDependencyError, as

Re: Support for `Q` objects in `get_or_create` and `update_or_create`

On Tue, Feb 20, 2018 at 6:39 PM Adam Johnson <m...@adamj.eu> wrote: > I think it's perfectly sane to document the filter + get_or_create combo, > feel free to open a ticket and pull request > > On 20 February 2018 at 20:26, 'Mike Lissner' via Django developers > (Contribut

Re: Support for `Q` objects in `get_or_create` and `update_or_create`

This is my first message here, and sure enough I'm necromancing this thread from 2016! Below there's a message about how to use Q objects with get_or_create by chaining them. This works! But it's not documented. Is it crazy to document this? I think I used the advice in this thread a while