On Sat, Aug 1, 2009 at 12:10 AM, Russell Keith-Magee<freakboy3...@gmail.com> wrote: > > 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 %-) > > > >
Indeed, I committed this solution last night. On to bigger, and better, and more bikesheddier things! Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
