Enhancement to the call_command function to allow the use of modules as arguments

I recently filed a bug about this and was redirected here for discussion. While using call_command (which simplifies calling management commands), it occurred to me that the API is a little strange. It currently is designed to work like this: c

Re: Enhancement to the call_command function to allow the use of modules as arguments

Thanks for the response, Aymeric. Comments inline. Mike On Sunday, August 16, 2015 at 1:41:19 PM UTC-4, Aymeric Augustin wrote: In general I would suggest to factor your business logic into a function > that you can call independently from the management command. This is better > for testing

Re: Enhancement to the call_command function to allow the use of modules as arguments

I see. Could this concern be addressed by adding it to the checks framework, so that it throws a warning if there are ever two commands with the same name? On Mon, Aug 17, 2015 at 11:16 AM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > 2015-08-17 16:54 GMT+02:00 Mik

Re: Enhancement to the call_command function to allow the use of modules as arguments

On Tuesday, August 18, 2015 at 12:00:30 PM UTC-4, Carl Meyer wrote: > > (Doc patches to better reflect that principle in the management command > docs are welcome, IMO.) > > Yeah, it's sounding like this is the change that's needed here. Probably the place to do that is here: https://docs.djan

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 d

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. Th

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 need

Re: Do people actually squash migrations?

/d/topic/django-developers/xpeFRpMTBZw/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/9d103a6d-1301-

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: https://docs.djang

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

as > incorrectly configured. > > Instead, we can shift 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 &g

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: How to do a counter in DB cache class?

even serialize > 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 d

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 bac

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

9148 Mike On Tue, Feb 20, 2018 at 6:39 PM Adam Johnson 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 > (