I'm splitting this conversation off from the other conversation on SQL logging, because I think that topic has merits all its own, and this one has more to discuss and slightly more possibility for backwards-incompatibility. I don't want to pork barrel this issue in with a perfectly legitimate one. :)
Russell Keith-Magee wrote: > On 8/9/07, George Vilches <[EMAIL PROTECTED]> wrote: >> So, my proposal is this: generate hooks for users. For each of the >> get_custom_sql/get_create_sql/etc., add a small portion that checks the >> installed apps for their own management.py file and an appropriate >> method. For instance, "sqlcustom"'s method could be >> "get_custom_sql_for_model_all", denoting that it's run on every model in >> every app that is having the current manage.py operation applied to it. >> These functions would be expected to return an array of SQL >> statements, which could then be fit in with the other generated SQL from >> each of the current built in methods. > > This is actually how the management commands started out - once upon a > time, you ran ./manage.py install myapp, which was a wrapper around > calling ./manage.py sqlall myapp and piping the output to the > database. > > The problem is that this approach isn't very flexible. Some of what > syncdb does isn't handled at a raw SQL level - we use the ORM to > generate the commands/queries etc. post_sync handlers, for example, > would be almost impossible to recode in the way you describe, and any > user-based post_sync handlers would need to support some sort of > 'retrieve sql' API. What I was proposing didn't involve taking the SQL code that Django generates and modifying it. Rather, this would allow the user to add more SQL that they generate entirely independently from what Django's internals are generating, but based on contents in the app (as opposed to static SQL files that can be loaded in). Example: Say I'm building a dynamic model. Say that, for whatever reason, I want this dynamic model to have a DB backing, just like any Django model. (I know there's already comments on the wiki as to the gotchas of this and why this may not be a great example, but it's the easiest one for me to explain). Well, syncdb works fine, if I have a signal to dispatch. But say I want to use something that doesn't have a signal, like "sql" or "sqldelete". I have no way to get my app's management method executed. So possibly, we get rid of "sql", "sqldelete" and the like, and only have "create", "delete", etc., which actually do the task, and like you said, have a --sql flag that does output only. If we do this, we still need to address how to call the user-level management.py code to make sure that all the extra user SQL is *always* included in every possible way the manage.py can be run. Here's the two options I see: 1) Add a signal to every option? Right now, only syncdb has a signal, although I have a ticket and patch for adding a signal to reset, see http://code.djangoproject.com/ticket/5065 . Doing this would be pretty straightforward, shouldn't break anyone's existing code (since we wouldn't be removing the syncdb signal, we'd just be making it more granular). Although, if we have a create signal and a delete signal, we'd need to make sure that when running a syncdb we don't also fire those signals. Easy enough, just something to be careful for. 2) Add a callback to every option? This is similar to the example I wrote in the first message. Less married to this with the idea of SQL logging and playback. My vote is for 1), I think with the playback feature, it would be pretty sexy, give us more functionality than is currently in manage.py, and fewer keywords to do so. I'll happily write the patch for it if there's no objections to the idea. The only thing that the idea currently breaks would be some of the old "manage.py" keywords, but the whole point of adding the logger and a --sql flag was to reduce the number of useless keywords we have in manage.py, which I'm fully +1 for. Too many redundant/easily merge-able options in there. :) Thanks, George --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
