Proposal: project-specific initial SQL data

[Yasushi Masuda]

Hello Djangonauts,

Currently we have all initial SQL data under app_dir/sql/. But I think it
would be better to add a hook to provide porject-specific initial SQL
data somewhere relevant to a project, for example:

1. project_name/sql/app/object_name(.db_engine).sql
2. settings.INITIAL_SQL_DATA_DIRS/app/object_name(.db_engine).sql

This will allow you to provide project-specific initial data for any
application easily.

As far as my short glance on
django.core.manageent.get_sql_initial_data_for_model, this change can be
done without breaking existing code behaviour.

I'm planning to submit a patch on trac, thus I'm happy to hear all your
comments, especially on:

1. Which strategy is more appropriate, example 1) or 2), or both?
2. How do project-specific initial data files treated: in my opinion,
project-specific data file should precede and alter the existing
application-provided sql initial data. If you want to customize
an initial data for an app, you may simply copy it from the app and
edit. Also, this behaviour resembles Django template precedence
policy.

Thanks,

--
Yasushi Masuda
http://ymasuda.jp/

[Adrian Holovaty]

On 1/13/07, Yasushi Masuda <whos...@gmail.com> wrote:
> Currently we have all initial SQL data under app_dir/sql/. But I think it
> would be better to add a hook to provide porject-specific initial SQL
> data somewhere relevant to a project, for example:
>
> 1. project_name/sql/app/object_name(.db_engine).sql
> 2. settings.INITIAL_SQL_DATA_DIRS/app/object_name(.db_engine).sql
>
> This will allow you to provide project-specific initial data for any
> application easily.

Hi Yasushi,

Thanks for posting this idea, but I do not believe this is a
worthwhile improvement -- in my opinion, it's feature creep. We're
always *very* hesitant to introduce new settings, and, more
importantly, there's nothing to prevent a developer from writing a
quick script that inserts initial data on a project-specific level
rather than an app-specific level.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

[Yasushi Masuda]

Adrian:

Thank you for comment.

I understood the policy not to creep the features, but let
me explain a bit about why I see benefit to have
proj_name/sql/app_name/obj_name.sql.

Just imagine we have an application comes with initial sql
data under the app directory. To customize app-provided initial
sql data, we must first install app with app-provided initial data,
then drop (a part or all of) them, and write and run some script(s)
to insert customized initial data.
If we have a hook to provide project-specific sql file (which
precedes any app-providing one as Django template does), the job
will become simple as just copying app-provided sql to project sql
directory, edit and install the app.

Yasushi Masuda
http://ymasuda.jp/

[Russell Keith-Magee]

On 1/14/07, Yasushi Masuda <whos...@gmail.com> wrote:
>
> Adrian:
>
> Thank you for comment.
>
> I understood the policy not to creep the features, but let
> me explain a bit about why I see benefit to have
> proj_name/sql/app_name/obj_name.sql.
>
> Just imagine we have an application comes with initial sql
> data under the app directory. To customize app-provided initial
> sql data, we must first install app with app-provided initial data,
> then drop (a part or all of) them, and write and run some script(s)
> to insert customized initial data.
> If we have a hook to provide project-specific sql file (which
> precedes any app-providing one as Django template does), the job
> will become simple as just copying app-provided sql to project sql
> directory, edit and install the app.

I should point out here that one of the goals of the Fixtures
framework (initial draft attached to ticket #2333) is to solve this
sort of problem. Using the fixtures framework, you can define initial
data sets in a database agnostic fashion (using a serialization format
like JSON or XML rather than SQL), and allow for multiple independent
fixture sets.

For example, you could have a 'US clients' fixture set, and an
'Australian Client' fixture set, which contains lists of instances of
User objects (from contrib.auth app), and some UserProfile objects (as
part of your application's models); when you sync, you could then
choose to install either or both of the either US Clients or AU
Clients data sets.

This hasn't been committed to the trunk yet, but the patches attached
to the ticket are probably pretty close to the final form; I'm hoping
to get some solid coding time in the near future to polish this
feature off. In the meantime, if you have any comments on the fixtures
framework as presented, they are most welcome.

Yours,
Russ Magee

[Yasushi Masuda]

Russ:

Thank you for advice. I shall look into the ticket and try the phase3-patch.