dumpdata refactoring

[Hovi]

As far as I know, there is not more granular control over dumping database fixtures.
I need to create fixtures in a more controlled fashion so I will do my own management command, I basically gotta copy-paste whole dumpdata management commant code and then modify relatively small part of it while keeping the rest the same.

The main logic of dumpdata it is directly in handle method, which makes it impossible to reuse. I'd like to refactor contents of this method into smaller methods so that I can reuse some of it and make it easier to use dumping functionality.

Is that something that would be welcome?

[Mariusz Felisiak]

Most of the customization should be handle with custom serializers. The ticket description doesn't provide any details about what you want to achieve that serializers cannot handle. Take into account that builtin management commands are not intended to be universal tools for handling all possible edge cases.

[Hovi]

I don't need to modify serializers. That's the part I want to reuse as it is. I don't expect management commands to be universal tools, but that doesn't mean they cannot be more flexible so that when I wanna customize them (because they are not universal enough for me), I can do that without just copy-pasting the whole file.

What I intend to do mostly is to create my own custom way to filter apps/models/model instances while pretty much keeping the rest the same.

One way how can I reuse it is to use call_command, passing loads and loads PKs but that is less flexible and definitely feels wrong for various reasons.