On Fri, Jul 31, 2009 at 8:34 AM, Jacob Kaplan-Moss<ja...@jacobian.org> wrote: > > Hi Alex, Russ -- > > I see some good pros and cons of each your suggestions. Just to throw > some more fuel on the fire, though, I've got an idea of my own: > > I tend to slightly favor introspection to identify old-style fields -- > it makes it easy to raise warnings/errors at the right point, for one > -- but I agree with Russ that the overhead of doing it all the time is > annoying, as is the slightly weird upgrade path. > > However, why not do the introspection once, when the field is created? > You could automatically wrap old-style methods with new-style > decorators (that discard `connection`) could easily check for the > existence of multiple databases and raise a > YouCantUseThisFieldTypeWithMultipleDatabases exception. > > Just sketching some code, I'd imagine it looking something like this:: > > # An old-style field doesn't need to change at alll... > class MyOldCustomField(models.Field): > def db_type(self): > ... > > # But a new-style field can needs to flag that it supports multiple > # database connections > class MyNewStyleCustomField(models.Field): > supports_multiple_connections = True > > def db_type(self, connection): > ... > > We could then key off `Field.supports_multiple_connections`, which > would default to `False`, and automatically wrap the given methods > (either in `__init__` or a metaclass; not sure which would be best). > > Further, this makes it very easy to raise warnings at startup time and > start the deprecation cycle of the old-style usages. In Django 1.4 > (Really? We're talking about 1.4 already?) > `supports_multiple_connections` becomes a noop. > > Thoughts?
I like this - a lot. It's a simple implementation. It completely avoids both the need to perform introspection and the API-name-change dance. It doesn't require a short lived wrapper function to call the underlying code. It forces users to be explicit about the upgrade process. Plus it provides a convenient place to raise deprecation warnings, and can be easily removed when we finalize deprecation. Alex - I think we have a solution! :-) Russ %-) --~--~---------~--~----~------------~-------~--~----~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
