On 04/18/2011 02:59 PM, Carl Meyer wrote:
Hmm. Why does it make sense for OneToOneField lookups to behave
differently from *_set managers? If I've got a default manager that
hides "deleted" objects, for instance: why should deleted objects by
default "not exist" when I traverse a reverse FK, but
Hi Raphael,
Yes, SimpleCookie is known to be an unpickleable class. We shouldn't
be directly pickling it anywhere in Django. In your code, you should
probably turn the cookie into a string before caching it. I'm not
clear if the bug you're experiencing is happening in Django's code or
something yo
Hi Johannes,
On 04/18/2011 01:45 PM, Johannes Dollinger wrote:
> Deprecate `use_for_related_fields` and always use the default manager
> for related managers. Then add the possibility to specify custom
> mangers for individual relations:
>
> ForeignKey(Foo, related_manager=RSpecialManager) ManyTo
On 04/18/2011 04:35 PM, Ivan Sagalaev wrote:
> Not exactly… I mean that when use_for_related_fields is set explicitly
> Django should respect it. Right now, as I understand from your first
> mail, it doesn't work as False when set to False. So I agree that this
> should definitely be fixed.
>
> Wh
On 04/18/2011 08:25 AM, Carl Meyer wrote:
FWIW, I don't think changing settings in general to be non-lazy is an
option - it will suddenly make a bunch of parts of Django dependent on
DJANGO_SETTINGS_MODULE at import time, where currently they only require
it at runtime (and even then perhaps only
On 04/18/2011 11:45 AM, Johannes Dollinger wrote:
I'd vote for (C).
Deprecate `use_for_related_fields` and always use the default manager for
related managers. Then add the possibility to specify custom mangers for
individual relations:
ForeignKey(Foo, related_manager=RSpecialManager)
On 04/18/2011 11:16 AM, Carl Meyer wrote:
By "just this" I presume you actually mean just the second half of what
you quoted ("explicitly set to False")? In other words, you're proposing
to make use_for_related_fields work as advertised, but make it default
to True instead of False?
Not exactly
Am 17.04.2011 um 01:30 schrieb Carl Meyer:
> So - do we (A) fix the behavior to match our documented semantics, note
> it in the release notes, and hope for the best? Or (B) bow to
> backwards-compatibility and change the documentation to match the actual
> behavior? Or (C) find some middle groun
On 04/18/2011 12:47 PM, Luke Plant wrote:
>> So - do we (A) fix the behavior to match our documented semantics, note
>> it in the release notes, and hope for the best? Or (B) bow to
>> backwards-compatibility and change the documentation to match the actual
>> behavior? Or (C) find some middle gr
Hi Ivan,
On 04/18/2011 01:07 PM, Ivan Sagalaev wrote:
>> even if "use_for_related_fields" is absent or explicitly set to
>> False on your Manager subclass.
>
> … the default manager should not be used as a base class. Fixing just
> this would be the best option because it retains current behavior
On 04/16/2011 04:30 PM, Carl Meyer wrote:
in general, related-object access for
reverse-FKs and M2Ms, contrary to the documentation, will _always_ use
your default manager (actually, a dynamic subclass of it)
It kind of makes sense. You don't want your deleted items to appear in
results just b
On 17/04/11 00:30, Carl Meyer wrote:
> So - do we (A) fix the behavior to match our documented semantics, note
> it in the release notes, and hope for the best? Or (B) bow to
> backwards-compatibility and change the documentation to match the actual
> behavior? Or (C) find some middle ground (a de
Hi Alex,
On 04/18/2011 02:44 AM, robim42 wrote:
> thank you for your answer. I also thought that owner_partner should
> work ... but when you try you get this:
Sorry, not owner__partner - since partner is only a field on Buyer, not
on Base, you'd need owner__buyer__partner.
In any case, I don't
Hi Ivan,
On 04/17/2011 10:38 PM, Ivan Sagalaev wrote:
> On 04/15/2011 02:20 AM, akaariai wrote:
>> I have been using setup_environ in my projects, and the lazy
>> initialization in can cause some weird problems, for example if you do
>> manual timing using:
>> start = datetime.now()
>> access sett
I see, thanks
Didn't know the existence of the lazy translation, so this is all a big
false alarm.
--
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 fro
Hi Viktor,
On 04/18/2011 09:14 AM, Viktor Kojouharov wrote:
> I think I might have stumbled upon a small bug. According to its docs,
> the 'verbose_name_raw' property is supposed to return an untranslated
> version of the 'verbose_name' property. However, if LANGUAGE_CODE is
> set, then 'verbose_n
We are thinking of organising monthly Django sessions in Leicester
with guest speakers on set topics that would interest fellow
Djangonauts.
Our plan is to organise a short 2 hour session each month on a
particular topic (e.g. Django + Celery, Django + NoSQL, GeoDjango +
MapServer, etc) with a pre
Hi,
I think I might have stumbled upon a small bug. According to its docs, the
'verbose_name_raw' property is supposed to return an untranslated version of
the 'verbose_name' property. However, if LANGUAGE_CODE is set, then
'verbose_name' would already be translated, provided that the user wrot
Some concerns, even if I don't know much about the subject.
Are you sure that it's always appropriate to strip indentation? Some
companies (like us) use templates for other stuff than HTML. (like
plain text mail.) In this case the indentation is meaningful (not to
the translator, but important for
Hi Carl,
thank you for your answer. I also thought that owner_partner should
work ... but when you try you get this:
>>> from multi.models import Seller, Buyer, Item, Base
>>> s = Seller.objects.get(name='Seller1')
>>> b = Buyer.objects.get(name='Buyer1')
>>> Item.objects.filter(owner__partner=s)
20 matches
Mail list logo
