#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 Matthijs Kooijman):
> 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.
I'm not married to the use of three management commands, if just
`dumpdata` and `loaddata` could achieve the same, that would also be
perfect (and using these two commands together does not seem like an
advanced scenario to me, really).
As for overriding an existing instance, I believe that the issue would not
be different when starting from a non-existing database. You would have to
run migrate, then, to create the table structure, which also runs the same
handles to create e.g. contenttypes.
One more thing I had wanted to emphasize in my previous comment: Using
external database tools is fine for backup and restore, but when moving
data between database types, making SQL-based dumps is pointless AFAICS
and some higher-level tool like `dumpdata` would be needed. If `dumpdata`
is not the tool for this, is there an alternative? Or is changing the type
of your database and/or moving data between instances with different
databases simply not supported by Django then?
This does not seem like a weird or unconventional usecase to me. On
particular instance of this is wanting to import some data from a
production server (typically mysql or postgres) into a local development
copy to reproduce some problem without having to debug on production. Of
course, you can have a staging copy of your application for this, or setup
mysql/postgresql locally, which certainly makes sense for big and
professional deployments, but for small-scale applications, this is a lot
of extra work just for this.
Apologies if I come across stubborn, but I feel that just saying "This is
unsupported" is insufficient in this case. Maybe this is extra annoying
because I'm not the first one to suggest this and this is a repeating
discussion for you, but if so that would be even more indication that this
usecase should be better documented (even if just as not supported).
Again, I would consider filing a documentation PR to clarify that this
usecase is not supported, but I'm still grasping a little bit at what is
and is not the intended usecase for `dumpdata` and `loaddata`. What
defines the line between supported and not supported?
--
Ticket URL: <https://code.djangoproject.com/ticket/31869#comment:5>
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.34e17c03d8d7766307b55b98c78a5b51%40djangoproject.com.
