#9549: Give initial_data.* files an option for not over writing current data.
-------------------------------------+-------------------------------------
Reporter: MrNarwhal | Owner: nobody
Type: New feature | Status: new
Component: Core | Version: 1.0
(Serialization) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: initial data, | Needs documentation: 1
syncdb, json, xml, yaml | Patch needs improvement: 0
Has patch: 1 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by chrisv):
Not sure whether this is the right place for discussing this, but I think
the --noclobber approach is not really the optimal solution for this
problem. IMHO, Django should differentiate between different types of
initial database content:
1.) data which is ''similar to code'' in a way that it is expected to
exist all the time and not be changed at all, for example a list of
countries or mime-types. This is what initial_data provides at the moment,
and for this kind of data it is correct to reset it after each syncdb.
2.) data which is ''similar to settings'' in a way that it is expected to
be there, but can be modified in a project, for example notification texts
which can be customized for a specific project/site. I believe this is
what this ticket was meant for originally.
3.) data which only serves as sample content, and is expected to be
deleted or modified in most cases, for example the "first post" in a fresh
Wordpress install. This is not necessarily in the scope of this ticket and
only mentioned for completeness.
With --noclobber, it is not really possible to differentiate between 1.),
2.) and 3.), instead it is only possible to tell syncdb to treat all
initial_data files to be one or the other. But how would the admin know
which data is what, and when to overwrite or not?
A much better approach would IMHO be to put this data into different files
and treat them respectively in syncdb, for example
* `system_data.(json|yaml|...)` contains data which is expected to be
overwritten by updates to the app (like current behaviour of initial_data)
* `custom_data.(json|yaml|...)` contains data which is only imported when
the pk does not exist, but not touched otherwise
* `demo_data.(json|yaml|...)` is only imported when the table has just
been created (I admit that one might be overkill, though - one can always
put it into another fixture which has to be loaded manually)
I'm willing to write a patch for this if core devs think this is
worthwhile.
--
Ticket URL: <https://code.djangoproject.com/ticket/9549#comment:10>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.96f81839a63aa1be76e9e3fe220f07cf%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
