* ui_ux: => 0
* easy: => 0
Comment:
I'm very interested in this feature, so I'd be happy to finish whatever
the ticket needs to be committed. Is documentation what has blocked this
ticket for 3 years now?
--
Ticket URL: <https://code.djangoproject.com/ticket/9549#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by aaugustin):
#15926 is related.
--
Ticket URL: <https://code.djangoproject.com/ticket/9549#comment:8>
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>
* status: new => closed
* resolution: => wontfix
Comment:
The new migrations framework doesn't load initial data any more.
--
Ticket URL: <https://code.djangoproject.com/ticket/9549#comment:11>