Hi Malcolm & James, I do think the SQL initial data is going to be a problem in a number of ways:
1) database API's (as per this thread) 2) line breaks ( c.f. http://code.djangoproject.com/ticket/2729 ) 3) database specific issues. For example - the sql file attached to the ticket above (2729) was exported with one of the mysql tools (prob. mysqldump), which magically adds backticks around the table names. SQLite does not like this, and from memory postgres won't either. I'm not sure what other glitches will be like this, but hopefully this is the only one. So - does the application developer try to manage one export for each database Django supports? Does django have to try to catch and handle that? Neither of these are terribly appealing. Suggestion: why not allow .py files inside the sql/ dir? These could be standard db-api commands, and run preferentially / prior to the .sql files. IMHO this would be nicer than hacking around with manage.py, and avoids all these problems. However, it does have (minor) security concerns - the .py file could contain arbitrary code, but this could be filtered. If this was added, then it'd be nice to allow exporting from tables in Django's db format too. This brings up another option, having .py scripts activate on installation would be very nice for things like oh, installing cron jobs, creating directories, etc. Maybe an /install/ directory which contains post-install scripts that get activated... --Simon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
