Re: Adding hooks to methods that generate SQL in django/core/management.py

Russell Keith-Magee wrote: > On 8/13/07, George Vilches <[EMAIL PROTECTED]> wrote: >> Russell Keith-Magee wrote: >>> The configuration option will need to be a little more generic - i.e., >>> putting the entire backend into a record mode - not just a single >>> cursor call. >> Second, we could add

Re: Changing the options in manage.py, adding more signals (was Re: Adding hooks to methods that generate SQL in django/core/management.py)

On 8/14/07, George Vilches <[EMAIL PROTECTED]> wrote: > > George Vilches wrote: > Unfortunately, since there's only a syncdb signal, I can't even do > things like a reset on it, and there's definitely no way currently to > get the SQL generated from my syncdb signal. Being able to get the > CREAT

Re: Changing the options in manage.py, adding more signals (was Re: Adding hooks to methods that generate SQL in django/core/management.py)

This sounds like a far more complicated example than I had considered when I was doing my work with dynamic models[1], but I did have success getting syncdb to install dynamic models, provided a few things are in order. I probably didn't document them well enough on the wiki, but I could do so if

Re: Changing the options in manage.py, adding more signals (was Re: Adding hooks to methods that generate SQL in django/core/management.py)

George Vilches wrote: > Russell Keith-Magee wrote: >> On 8/12/07, George Vilches <[EMAIL PROTECTED]> wrote: >>> 1) Add a signal to every option? >> If we were going to go down this path, this would be the preferred >> option. However, I'm not sure I'm convinced of the need. Which >> commands exact

Re: Changing the options in manage.py, adding more signals (was Re: Adding hooks to methods that generate SQL in django/core/management.py)

Russell Keith-Magee wrote: > On 8/12/07, George Vilches <[EMAIL PROTECTED]> wrote: >> 1) Add a signal to every option? > > If we were going to go down this path, this would be the preferred > option. However, I'm not sure I'm convinced of the need. Which > commands exactly do you think require si

Re: Changing the options in manage.py, adding more signals (was Re: Adding hooks to methods that generate SQL in django/core/management.py)

On 8/12/07, George Vilches <[EMAIL PROTECTED]> wrote: > > 1) Add a signal to every option? If we were going to go down this path, this would be the preferred option. However, I'm not sure I'm convinced of the need. Which commands exactly do you think require signals? Yours, Russ Magee %-) --~--

Re: Adding hooks to methods that generate SQL in django/core/management.py

On 8/13/07, George Vilches <[EMAIL PROTECTED]> wrote: > > Russell Keith-Magee wrote: > > The configuration option will need to be a little more generic - i.e., > > putting the entire backend into a record mode - not just a single > > cursor call. > > Second, we could add a class level variable to

Re: Adding hooks to methods that generate SQL in django/core/management.py

On 8/13/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Brian Ferring seems to be on top of this one. There's a separate Bother. That should be Brian Harring. Apologies Brian. Russ %-) --~--~-~--~~~---~--~~ You received this message because you are subscribe

Re: Adding hooks to methods that generate SQL in django/core/management.py

Russell Keith-Magee wrote: > On 8/12/07, George Vilches <[EMAIL PROTECTED]> wrote: >> How about the patch below? When you create the cursor, if you want >> access to "don't run this SQL, just have playback available", just use >> connection.cursor(playback_only=True), and if you want to roll the

Re: Adding hooks to methods that generate SQL in django/core/management.py

On 8/12/07, George Vilches <[EMAIL PROTECTED]> wrote: > > How about the patch below? When you create the cursor, if you want > access to "don't run this SQL, just have playback available", just use > connection.cursor(playback_only=True), and if you want to roll the This is a simple approach tha

Re: Adding hooks to methods that generate SQL in django/core/management.py

On Sun, Aug 12, 2007 at 09:20:06AM -0400, George Vilches wrote: > Something that I found a little irksome while working on this is that > the DatabaseWrapper class for each backend doesn't inherit from some > logical parent. I know that all the db-specific functionality is > wrapped by these cl

Changing the options in manage.py, adding more signals (was Re: Adding hooks to methods that generate SQL in django/core/management.py)

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 legitimat

Re: Adding hooks to methods that generate SQL in django/core/management.py

Russell Keith-Magee wrote: > I would suggest approaching this problem at lower than that - > installing a filter at the level of the database cursor that diverts > queries away from the actual database, and into a store. That way, if > you run the code 'Author.objects.all()' , the backend will ge

Re: Adding hooks to methods that generate SQL in django/core/management.py

On 8/9/07, George Vilches <[EMAIL PROTECTED]> wrote: > But, these cases still wouldn't allow you to just print this > additionally generated SQL, or in any way retrieve and use it from any > of the other commands (sql, sqlclear, etc.). This is sometimes > frustrating, as these additional SQL sta

Adding hooks to methods that generate SQL in django/core/management.py

I find that on a few occasions, I've needed to generate extra SQL for both creation and deletion tasks when I'm executing "manage.py syncdb" (or sql, or reset, sqlclear, etc., pretty much all of the SQL generation commands). Currently, if you use only use syncdb for everything, you can do thi