Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
Django developers
Home
+ new post
About this group
Join this group
Message from discussion Changing the options in manage.py, adding more signals (was Re: Adding hooks to methods that generate SQL in django/core/management.py)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
George Vilches  
View profile  
 More options Aug 12 2007, 9:49 am
From: George Vilches <g...@thataddress.com>
Date: Sun, 12 Aug 2007 09:49:17 -0400
Local: Sun, Aug 12 2007 9:49 am
Subject: Changing the options in manage.py, adding more signals (was Re: Adding hooks to methods that generate SQL in django/core/management.py)
Print | View thread | Show original | Report this message | Find messages by this author
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 <g...@thataddress.com> 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 must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google