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 useful is a dictionary of > alternate SQL code generating plugins. You could then plugin a custom > SQL generator by name in a given model Meta class. With this approach > you could create plugins that would create alternate table formats > such as partitioned tables, or app-specific DB views or such. You > could also create and use a plugin that generates no SQL at all which > would handle the use case targeted by the fix to #3163.
That would be overkill as a solution to #3163. A simple flag that indicates not to call the creation code works well for that ticket. I don't really like it as a general thing, either, since doing this on a per-model basis gets really complicated really fast. In terms of maintainability it feels like it would be much harder to manage than the existing plan and implementation of having all the SQL generation in one place. 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. 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 django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---