#31869: Improving data migration using `dumpdata` and `loaddata`
-------------------------------------+-------------------------------------
Reporter: Matthijs Kooijman | Owner: nobody
Type: New feature | Status: closed
Component: Core (Management | Version: 3.1
commands) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by felixxm):
> I was not talking about backups here (I agree that database-specific
tools are better for this, though I could also see `dumpdata` as a second-
best option), but about copying data from one instance to another. But
that's just a matter of definition, I'm assuming that you would also
consider that dumpdata is not meant for such data copying?
Sure you can use `dumpdata` to create a copy of data but you're talking
about a specific and advanced scenario (combination of 3 management
commands) for overriding and existing and not empty instance. IMO, this is
not something that we want/should support or document.
You've already mentioned in the ticket description that it's possible if
you exclude Django apps that use the `post_migrate` signal and use natural
keys in `dumpdata`, however I don't think we should document this because
`dumpdata` isn't meant as a backup/clone tool.
--
Ticket URL: <https://code.djangoproject.com/ticket/31869#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/074.eb716735f87c083fdececf51b0d4b6a1%40djangoproject.com.
