Re: [Django] #3148: Add getters and setters to model fields
Django
-------------------------------------+-------------------------------------
Reporter: jerf@… | Owner:
Type: New feature | Status: new
Component: Database layer | Version: SVN
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by inactivist):
* cc: inactivist@… (added)
* ui_ux: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/3148#comment:47>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: jerf@… | Owner:
Type: New feature | Status: new
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by akaariai):
I have a feeling this ticket needs to be wontfixed. The reason is that it
seems the setter should not be called in model.`__init__` if the object
comes from the DB. On the other hand, `__setattr__` must be called for
backwards compatibility reasons. I don't see how to achieve this: you
can't assign to the attribute in `__init__` - setter will not be called.
You can't assign to `__dict__` - setattr will not be called. In addition
the solution must not cause any severe performance regressions to
`__init__`
We have managed to live without this feature to this day. Maybe it is time
to just let this feature go?
--
Ticket URL: <https://code.djangoproject.com/ticket/3148#comment:48>
Django
-------------------------------------+-------------------------------------
Reporter: jerf@… | Owner:
Keywords: | Needs documentation: 1
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
Indeed, this could introduce subtle backwards incompatibilities for people
who have overridden `__setattr__`. I don't believe this had been noticed
until now.
An earlier comment claims that "the desired behaviour is simple as hell",
but that isn't backed by any code and the analysis includes some hand-
waving. I see that the latest patch, which is the 14th attempt at doing
this correctly, still contains a comment saying it's a hack, and it alters
`__bases__`. I'm not comfortable with such techniques, to say the least.
My recommendation would be to call the field `_foo` and have a `foo`
property on your model that actually gets/sets `_foo`. This might seem
unclean, but it's absolutely transparent, and the relation with the ORM is
totally obvious. It's also immune to the multiple-execution problem.
If you have a better idea — and enough arguments to convince the core team
that it doesn't have side effects such as the one found by Anssi — please
make your case on django-developers. Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/3148#comment:49>
Django
-------------------------------------+-------------------------------------
Reporter: jerf@… | Owner:
Type: New feature | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by anonymous):
Anyone looking for a simple answer to this problem without using an
underscore in the database could try:
http://www.korokithakis.net/posts/how-replace-django-model-field-property/
{{{
classMyClass(models.Model):
_my_date=models.DateField(db_column="my_date")
@property
def my_date(self):
return self._my_date
@my_date.setter
def my_date(self,value):
if value>datetime.date.today():
logger.warning("The date chosen was in the future.")
self._my_date=value
}}}
Augustin's solution was half complete.
--
Ticket URL: <https://code.djangoproject.com/ticket/3148#comment:50>
Django
-------------------------------------+-------------------------------------
Reporter: jerf@… | Owner:
Type: New feature | Status: closed
Component: Database layer | Version: master
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by ariel17):
This solution does not work well on templates because they cannot see a
field starting with "_". Also queries cannot be done on this field (for
example, when writing a custom model manager) because referencing the
field "_field" confuses the ORM with field joining.
--
Ticket URL: <https://code.djangoproject.com/ticket/3148#comment:51>