I was taking a look at Ticket #3163 which, when incorporated into
Django, would add a Meta flag to the model which disables SQL code
generation. It occurred to me that on a conceptual level, this fix is
wrong. What would be more generally useful is a dictionary of
alternate SQL code generating plu
OK then. Here is my concept for 2 small hooks...
Let the backend do it's thing and create the table creation SQL in the
normal manner. Right before executing that SQL call a hook function,
if present, gets to modify the SQL or change it to None to suppress
the SQL call entirely. There is also a
On Sun, 2008-10-05 at 17:59 +1100, Malcolm Tredinnick wrote:
>
> On Sat, 2008-10-04 at 23:49 -0700, Rock wrote:
> >
> > > In any case, you can already do what you want using custom managers. You
> > > return a custom queryset that generates the query however you like.
> > > Lifting all that up
On Sat, 2008-10-04 at 23:49 -0700, Rock wrote:
>
> > In any case, you can already do what you want using custom managers. You
> > return a custom queryset that generates the query however you like.
> > Lifting all that up into Meta doesn't seem necessary to me.
> >
>
> Good feedback Malcolm, bu
> In any case, you can already do what you want using custom managers. You
> return a custom queryset that generates the query however you like.
> Lifting all that up into Meta doesn't seem necessary to me.
>
Good feedback Malcolm, but I don't understand that last statement. In
the case of parti
On Sat, 2008-10-04 at 04:51 -0700, Rock wrote:
> I was taking a look at Ticket #3163 which, when incorporated into
> Django, would add a Meta flag to the model which disables SQL code
> generation. It occurred to me that on a conceptual level, this fix is
> wrong. What would be more generally use
