Howdy --
Russ, I can't thank you enough for your work on this stuff. Half
these edge cases I wouldn't have even thought of 'til they bit me in
the ass -- I really appreciate it :)
Now, onto your questions:
> I propose that: 'Article.reporter_set = X' be allowed, where X is any
> iterable. The assignment results in the relation set being cleared and
> replaced with all items in X.
+1; this is clear and concise. Kieren's objection about the
implication of ordering is a valid one, but I think most Python
developers are comfortable with the idea of different types of
iterables behaving differently. This also allows such constructions
as::
Article.reporter_set = Reporter.objects.filter(...)
Which "feels right" to me.
> Rather than allowing
> any iterable or single object, only allow sets on the assignment.
I'm -0 on this; seems too restrictive, and since the use will usually
be to construct a throwaway set from a list, let's just allow the list.
> 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?
I think that if the foreign key is None (for whatever reason), then
__get__ should return None; otherwise it should expect a valid
reference to exist and raise DoesNotExist. (For template authors,
note that DoesNotExist exceptions are swallowed silently by the
template engine so you don't have to worry about being bitten by this).
My reasoning is that if I do::
article.reporter_id = some_non_existant_id
print article.reporter
I should get an exception, but if I construct a Article with an empty
(i.e. None) reporter_id, I should get None.
> 3) What is to become of the _id fields for ForeignKeys?
They need to stay around for efficiency; I'd like not to have to do a
db hit just to find the id of something I've already got. Often in
bulk-data-import situations you have the need to monkey with ids, and
the few db hits the better.
> This bit me recently because a1.reporter_id = r.id is still legal
> syntax, but doesn't update/flush the cache for a1.reporter.id. If _id
> is to be retained, how is single object descriptor caching to be
> handled to avoid this sort of problem?
I'm not sure this is solvable; I'd say that if people set ids
manually they need to remember to call ``save()``.
> 4) Reverse descriptors and save() have an interesting relationship.
[snip]
> a) make add()/remove()/clear()/__set__ implicit save points. This
> would have the added bonus of making ForeignKey add() etc mirror
> ManyToMany add() behaviour (since m2m table additions occur
> immediately, where ForeignKey add()'s are not applied until save() on
> the underlying objects)
Like hugo, I like this approach, and for all the same reasons he
gave. However, I'd say I'm +0.9 -- if there's a better solution I'd
like to have it, but damned if I can think what it might be.
Jacob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" 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-developers
-~----------~----~----~----~------~----~------~--~---
