#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: [email protected] | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------
Comment (by semenov):
Wrong. Lack of a correct implementation does '''not''' mean the initial
problem doesn't worth solving it. Logically, the desired behaviour is
simple as hell - do not run setters/getters when Django does its ORM
things (that is: object fetching, construction, saving, deleting, caching,
etc.), but always call getters/setters when a model is used from from an
external (business logic) code. I don't see anything strange or hard or
inconsistent from the architectural point of view either. The ORM - which
is aware of the essence of the models - should work with the data directly
using internal structures (!__dict!__ or whatever), and all the other
unaware code should be using the "frontend" properties.
The "simple enough that it works as it first appears" approach is
ultimately doomed. If everyone was adopting this kind of thinking, there
would be no ORM at all and we'd be running manual SQL queries which are
"simple enough that they work as they first appear". Abstractions always
leak and there will always be trade-offs, but that doesn't mean we should
stop creating them. We should only stop when the gain is less than the
cost, which is clearly not the case for getters and setters.
By the way, I am more and more thinking that the part of the confusion
comes from that everyone is talking about BOTH getters and setters. In my
opinion, '''we should have only setters'''. As the data is backed by a
database, ''reading'' should always return what the database actually
holds (with respect to Field.to_python(), of course). However, ''setting''
is different and needs to be able to be overriden indeed - because that
allows to implement additional validation, transformation (e.g. proper
formatting), and other things like logging.
One of the clear examples is using Model Forms. Right now, the whole
powerful concept is barely useful for any non-trivial models, because you
can't just call modelform.save() and expect it to call all setters
properly -- instead, you always have to code all that manually. However, I
can't imagine any example where a ''getter'' would be of any use.
--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:35>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
