Opened 14 years ago
Closed 14 years ago
#14914 closed (wontfix)
Let to_python (in custom db field) know the connection being used in multi-db environment
Reported by: | liangent | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.2 |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
get_prep_* methods have get_db_prep_* now. What about to_db_python, or adding another argument to to_python?
Change History (2)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
get_prep_value *doesn't* take a connection argument, because it is the connection-agnostic portion of data preparation. get_preb_db_value *does* take a connection argument, because it represents the connection-specific data transformation.
to_python should also be connection-agnostic -- as evidenced by the fact that it is often invoked by get_prep_value. It's also used by serializers and form handlers, both of which are connection agnostic.
In short, there's no reason that to_python should need a connection argument.
As for adding to_db_python -- why is this method required? The fact that Django's fields work fine without needing a database-side to_python implementation is pretty strong evidence that such a method isn't required. We're not going to add a method "just because" -- there needs to be a use case.