Code

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#1978 closed enhancement (wontfix)

Create Initial data via database API instead of SQL

Reported by: anonymous Owned by: adrian
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: UI/UX:

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.

Attachments (0)

Change History (3)

comment:1 Changed 8 years ago by mtredinnick

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 Changed 8 years ago by ian@…

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 Changed 8 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.