Opened 18 years ago

Closed 18 years ago

Last modified 18 years ago

#1978 closed enhancement (wontfix)

Create Initial data via database API instead of SQL

Reported by: anonymous Owned by: Adrian Holovaty
Component: Core (Management commands) Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The ability to insert initial data via SQL is documented at http://www.djangoproject.com/documentation/model_api/#providing-initial-sql-data. However, Django already provides the OR mapper and database API, and it would be nice to create initial data using those tools. The initial SQL data documentation discusses putting ".sql" files in <appname>/sql/<modelname>.sql. I would like to add the ability to execute special files in a similar location (i.e., <appname>/SOMEPLACE/<modelname>.py, where SOMEPLACE is "data" or "load" or something like that), so that database API calls like the following could be used (given the appropriate import statements for each):

in mymodel.py:

Mymodel(name="Fred").save()

in mymodel2.py:

# Mymodel2 has an "other" field, which is a Foreign Key field (to Mymodel)
Mymodel2(name="baz", other=Mymodel.objects.get(name="Fred")).save()

I think the syntax looks a little wordy (maybe an opportunity for a convenience method on the Model class?), but it allows my to create objects, including relationships among the model classes.

In this scenario, there would need to be a way to ensure the order of execution, or we would need to be able to put creation statements for multiple models in a single script file.

Change History (3)

comment:1 by Malcolm Tredinnick, 18 years ago

This proposal, to some extent, increase the "magic" involved in running manage.py again. We need to have the initial data SQL files, because there are things you can do there that you cannot do through the ORM and it also provides a very compact form for inserting initial data. But I think we should keep this kind of running of extra files to a minimum. It's easy enough to wrap up a call to manage.py followed by a call to your own .py file in a shell script if you want to do this for individual projects.

Having arbitrarily many options for doing the same thing leads to confusion that outweighs utility at some point. I don't see this option as adding a feature that is otherwise hard to do.

comment:2 by ian@…, 18 years ago

Hi mtrednick

the reason why I like this proposal is:

  • it is DB-engine independent.
  • it allows you to insert records whose keys aren't known at the start

maybe you can have both? have manage call a setup.py if it exists ? (as well as just load SQL if they exist) that way you could set up other things like upload directories and even install things in the htdocs area

comment:3 by Adrian Holovaty, 18 years ago

Resolution: wontfix
Status: newclosed

You can use the (yet undocumented) django.dispatch framework for this. It's not worth adding another explicit hook.

Note: See TracTickets for help on using tickets.
Back to Top