On Fri, 2006-09-15 at 20:32 -0700, [EMAIL PROTECTED] wrote: > 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.
Which makes it no longer SQL. > 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. Let's not conflate multiple problems here. Importing not-SQL and trying to treat it as SQL is not a problem we are going to solve with initial SQL import. If you want to have portable input data, you have to write proper SQL. If you don't mind being tied to one particular vendor then you can use extensions like backticks, but it would be crazy for Django to try and "normalise" data at the initial SQL import phase to support cross-vendor portability like this. Getting the import of SQL correct is hard enough. > 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. If the application developer wants their data to work on multiple databases, they should ensure it is dumped in portable SQL format. That is usually possible. If not and more intelligence is required, they can drop back to the Python language and examine settings.DATABASE_* to work out what to do. > 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. We already allow arbitrary Python hooks: http://www.bright-green.com/blog/2006_07_12/initialising_application_data_.html . So we have raw SQL and Python hooks. Adding more and more options to do those things in slightly different ways is not something I'd be in favour of. Cheers, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
