#9589 http://code.djangoproject.com/ticket/9589 was closed for a
reason that didn't make any sense--it looks like someone closed the
ticket after reading only the first comment. The later patches fixed
those problems. I asked about this in the ticket, but didn't get a
response.
ly parse this out if it's present,
and test against that revision (else trunk). This also makes the test
results much more fixed and reproducable.
(Answering the question "does the patch still work today" is useful
too, but would probably need some external interface to request that a
p
-django-core:
development on Django itself, and more importantly, it would have been
completely unambiguous to users developing using Django.
But it's obviously not worth changing now. That's why I said "would
have been". The notion of inverting the me
cription is going to fix the unintuitive naming.
--
Glenn Maynard
--~--~-~--~~~---~--~~
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@google
nceived
warnings might want you to believe.) But with these limitations, it
may not be worth the bother for most people.
--
Glenn Maynard
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" gr
;s generated by a view or a request
> middleware, so let's be consistent on the exception path, too.)
I suspect this patch still doesn't handle this, since there are no tests for it.
--
Glenn Maynard
--~--~-~--~~~---~--~~
You received this message
are exception, but it was triggering on a
request that wasn't a concern at the time and I had been ignoring
it--and it didn't occur to me that it could cause problems with other
requests. Of course, I've fixed my middleware which exposed this
problem, but the general problem of clean
ot;oh, this is meant to behave like a
> subclass of that other model".
I find the "zero or one to one" case much more commonly useful, and
OneToOneField is much more natural for that (because ForeignKey's
reverse gives a set)
eld instead of ForeignKey for the profile's user field?
It's a better fit; this seems like a relic from before OneToOneField
was stable.
http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users
--
Glenn Maynard
--~--~-~--~~~--
your applications will immediately
> understand what's going on.
I don't think "user.get_profile()" is measurably clearer than
"user.profile", though I guess it would be if you named your profile
class "Teapot".
--
Glenn Maynard
--~--~-~--~~---
revents people from
ignoring get_profile entirely and just using OneToOne (which is
probably what I'll do).
--
Glenn Maynard
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To po
tent.
> oh, and this list is for the development of django.
> Question about the usage of django should be directed at django-users.
I'm well aware of both lists. This is a question about the design
(development) rationale of Django.
--
Glenn Maynard
--~--~-~--~~~--
rationale here.
--
Glenn Maynard
--~--~-~--~~~---~--~~
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
type should
have its own type, for the same reason OneToOne exists--it's a
distinct type of relationship. I don't know what it would be called,
though; "OneToZeroOrOne" is awkward.
I don't think this wins anything over a flag in OneToOne, though,
other than an awkward class
icket/5741: "make queryset get() take a
default", but without the backwards compatibility problem.)
--
Glenn Maynard
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To pos
I'm very interested in a cleaner transaction interface. I just wrote
a contextmanager to do the usual "run this code in a transaction" bit,
and it took a day and a half instead of a few minutes.
The goals were typical: to be able to make SQL calls atomically,
without caring about whether a trans
16 matches
Mail list logo
