On 9/15/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > In general, initial SQL data is a real pain to manage and if anybody has > a good idea on a better approach. I would like to avoid building a full > SQL parser in Python for obvious reasons.
Other people already *have* built SQL parsers in Python, with all the quirks of specific databases, so... why not either A) Do away with initial SQL entirely, and move to officially recommending people set up a 'management.py' file in their apps which hooks the post_syncdb signal to do whatever's needed -- up to and including grabbing the database cursor and executing statements directly, or B) Keep initial SQL around, but encourage more use of the management/post_syncdb routine, and possibly limit the range of statement types which can be executed in an initial SQL file (say, by limiting to just INSERT statements; since the management function for viewing these statements is called "sqlinitialdata", it makes sense that its purpose would be to populate data into a table immediately after creation). -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
