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?
Jacob
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
