On Fri, 2006-09-15 at 21:22 -0500, James Bennett wrote: > 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
My gut feeling is that this is restrictive. I know you're a big fan of the "Django not for everything" school of thought (me, too, in some sense and I respect your position, but my exclusion range is much smaller). I want to see how far we can go to being as accommodating as possible. I like the idea of being able to work smoothly with legacy databases and other tools and often the easiest way to do this is to be able to initialise from a partial SQL dump. Not having to do an SQL dump and then rewrite into Python. I'll acknowledge that's a bit of a spit-and-polish mentality, though, and it's mostly why I haven't worried too much about this up until know beacuse (a) there are always work-arounds and (b) there are much higher priority things. > 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). That's what we do currently -- only support certain types of inserts, etc (it's just that the particular set we support today is a little amorphous, depending upon which tickets have been fixed). This somewhat strikes me as a "we'll fix this problem in the documentation" solution, which feels a little awkward (and consequently we end up doing it even worse, but neither documenting nor fixing the root cause ... nobody said the universe was fair). For now, I was floating this as a "if somebody wants something to think about and work on" problem; it's not going to interrupt my flow very much, personally, at the moment. Regards, 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 -~----------~----~----~----~------~----~------~--~---
