> 2) If a related attribute currently has a value of None, should the
> __get__ method return None, or raise a DoesNotExist if accessed? Does
> this behaviour change if the attribute is set null=True?
>
> Personally, I am:
> +1 returning None if null=True
> +0 returning None if null=False
>
> 3) What is to become of the _id fields for ForeignKeys?
>
> The descriptor work has always talked about reporter.id becoming the
> new notation for reporter_id, but reporter_id is still there.
>
> Is this an oversight, or a design decision that I have missed?

These two both relate to an additional issue.  In the proposal,
a1.reporter.id would not do a DB lookup.  In order to achieve this,
a1.reporter would have to return a lazy object with just the ID set,
and other attribute access would cause the data to be fetched.

In that case article.reporter.name would have to throw an exception of
some kind (because 'None' could be ambiguous - the reporter's name
might be null).  The problem I have with that is it means you can start
getting errors much later, and it isn't obvious when you would get
them.

I think a way around these problems is to have __nonzero__ implemented
on the lazy object.  If the id was null, __nonzero__ would return false
(i.e. the object is 'False').  Otherwise, it would do a DB lookup and
if for some reason the object wasn't there in the DB it would return
False, otherwise True.  This way, you could right:

{% if article.reporter %}
  Name: {{ article.reporter.name }}
{% endifequal %}

in the templates, or similar python code.


Luke


--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---

Reply via email to