Re: Is using version 2 of the pickle protocol in {DB,FileBased}Cache

[Paul McMillan]

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 your application is doing directly with SimpleCookie.

The last memcached backend I looked at pickled things using the
highest protocol. I don't remember which one it was. It's very odd
that you're not seeing the same error using memcached.

Locmem should use the highest version of pickle, to more closely
mirror the behavior of memcached. I'll open a ticket about that.
Django shouldn't switch to the earlier versions of pickle for
performance reasons.

I think that your provided test case is trying to do something that is
explicitly not supported, but I'm unclear on whether or not there is
an issue in Django-provided code. Could you provide a little more
information?

Thanks,
-Paul

On Fri, Apr 15, 2011 at 1:23 PM, Raphael Kubo da Costa
 wrote:
> Hello there,
>
> I was experiencing some problems with Django's caching system on 1.2.X
> (1.2.5, to be more specific) when using either the database or the
> file-based backends.
>
> Both use pickle and call pickle.dumps(..., pickle.HIGHEST_PROTOCOL) when
> serializing the data after being called by UpdateCacheMiddleware.
>
> However, it looks like pickle does not play nice with SimpleCookie-based
> classes [1]. In the first request (still not cached), the csrf token is
> set correctly as follows:
>
>  Set-Cookie:  csrftoken=XX; Max-Age=31449600; Path=/
>
> When the same view is requested again, though, the cookie is retrieved
> incorrectly from the cache by FetchFromCacheMiddleware:
>
>  Set-Cookie:  csrftoken="Set-Cookie: csrftoken=XX Max-Age=31449600\073 Path=/"
>
> The locmem, dummy and memcached backends do not present this problem:
> locmem does not specify the protocol version when calling pickle.dumps,
> which means protocol version 0 will be used; dummy does not do anything
> and memcached does not use pickle. Pickle protocol versions 0 and 1 work
> fine.
>
> The following patch to the unit tests should break both
> FileBasedCacheTests and DBCacheTests. I only tested it against the 1.2.X
> git branch, but 1.3.X should present the same behaviour, and both Python
> 2.7.1 and Python 3.2 fail.
>
> diff --git a/tests/regressiontests/cache/tests.py 
> b/tests/regressiontests/cache/tests.py
> index 0581e4e..5611eef 100644
> --- a/tests/regressiontests/cache/tests.py
> +++ b/tests/regressiontests/cache/tests.py
> @@ -285,6 +285,22 @@ class BaseCacheTests(object):
>         self.assertEqual(self.cache.get("expire2"), "newvalue")
>         self.assertEqual(self.cache.has_key("expire3"), False)
>
> +    def test_cookie_caching(self):
> +        try:
> +            from Cookie import SimpleCookie
> +        except ImportError:
> +            from http.cookies import SimpleCookie
> +
> +        test_cookie = SimpleCookie()
> +        test_cookie['key'] = 'some value'
> +
> +        self.cache.set('some_cookie', test_cookie)
> +
> +        cached_cookie = self.cache.get('some_cookie')
> +
> +        self.assertEqual(cached_cookie['key'].value,
> +                         test_cookie['key'].value)
> +
>     def test_unicode(self):
>         # Unicode values can be cached
>         stuff = {
>
> [1] http://bugs.python.org/issue826897
>
> --
> Raphael Kubo da Costa
> ProFUSION embedded systems
> http://profusion.mobi
>
> --
> 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 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #14891, a.k.a. "related managers don't work how we claim they do"

[Carl Meyer]

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) ManyToManyField(Foo,
> manager=SpecialManger, related_manager= RSpecialManager)
> 
> More fine grained control would especially be useful for subclasses
> of ForeignKey and ManyToManyField fields. It comes at the expense of
> verbosity, but it appears to be a rarely used feature (given that the
> bug was discovered only now). And thus, explicitness might actually
> be a good idea.

Do you have real-world use-cases in mind that require per-relation
manager configuration? I can't think of any uses I've run across that
weren't workable with a single default manager used by all relations.

Carl

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #14891, a.k.a. "related managers don't work how we claim they do"

[Carl Meyer]

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.
> 
> What I was saying is that when this attribute is not set current
> behavior does make sense:
> 
> - use default manager as a base for *_set managers
> - use pure manager as a base for OneToOne and parent lookups
> 
> However it can't be described with neither "False by default" nor "True
> by default". I think it's fine and we could just thoroughly document
> this behavior.

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 "exist" when I
traverse a OneToOneField?

Simply from a complexity-of-documentation standpoint I don't like the
idea that the effective "default" for use_for_related_fields would be
neither True nor False, so to counterbalance that I'd want a pretty
strong case for why it's the best option.

Carl

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Accidental logging disabling

[Ivan Sagalaev]

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 when certain functionality is
used).

I do, however, think that it would be fine to have the setup_environ
function explicitly trigger settings-loading. This should never be a
problem, because setup_environ already sets DJANGO_SETTINGS_MODULE. It's
also not an invasive change at all - it should be a one-liner, I think.


After some thinking I agree with you.


That might be reasonable as well - I'm interested to hear Russell speak
to that


Ditto.

--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #14891, a.k.a. "related managers don't work how we claim they do"

[Ivan Sagalaev]

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)
  ManyToManyField(Foo, manager=SpecialManger, related_manager= 
RSpecialManager)


I like this one too! Except for the "always use the default manager" 
part which, as Carl noted elsewhere in the thread, is not how it works 
right now. Different relation lookups use different defaults. But your 
idea expresses this even better.


--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #14891, a.k.a. "related managers don't work how we claim they do"

[Ivan Sagalaev]

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… 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.


What I was saying is that when this attribute is not set current 
behavior does make sense:


- use default manager as a base for *_set managers
- use pure manager as a base for OneToOne and parent lookups

However it can't be described with neither "False by default" nor "True 
by default". I think it's fine and we could just thoroughly document 
this behavior.


P.S. Sorry for being sloppy with my first reply…

--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #14891, a.k.a. "related managers don't work how we claim they do"

[Johannes Dollinger]

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 ground (a deprecation path for the
> current behavior)?

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)
 ManyToManyField(Foo, manager=SpecialManger, related_manager= 
RSpecialManager)

More fine grained control would especially be useful for subclasses of 
ForeignKey and ManyToManyField fields.
It comes at the expense of verbosity, but it appears to be a rarely used 
feature (given that the bug was discovered only now). And thus, explicitness 
might actually be a good idea.

And it would be a step towards discouraging use of multiple 
managers.

__
Johannes

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #14891, a.k.a. "related managers don't work how we claim they do"

[Carl Meyer]

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 ground (a deprecation path for the
>> current behavior)?
> 
> I vote for A - fix the bug.

That's my leaning, too.

The biggest pain this would cause would be for people using third-party
custom managers that don't set use_for_related_fields, and relying on it
being used for related fields anyway. Since use_for_related_fields
currently must be set as a class attribute, not an instance attribute,
they would either need to subclass the third-party manager just in order
to add use_for_related_fields=True, or they would need to monkeypatch it on.

In my mind, this reveals a different problem: the author of a custom
Manager subclass is not necessarily the best person to decide whether
that manager should be used for related fields in a particular use of
it. Making Manager.__init__ accept a use_for_related_fields argument is
problematic for backwards-compat with existing subclasses, but we could
respect it if set directly as an instance attribute:

   objects = MyCustomManager()
   objects.use_for_related_fields = True

I may open that as a separate ticket.

Carl

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #14891, a.k.a. "related managers don't work how we claim they do"

[Carl Meyer]

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 by
> default while allowing other uses if needed.

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?

If I were designing this from scratch, I think I would also prefer
use_for_related_fields to default to True. But that would be a
non-bugfix change that would impact backwards-compatibility for things
that currently do properly respect use_for_related_fields. For example,
people might suddenly start getting ObjectNotFound from a OneToOneField
descriptor where previously they got the "hidden-by-default-manager"
object back. So I think we could only do that with some kind of
deprecation path for the current default of False.

Carl

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #14891, a.k.a. "related managers don't work how we claim they do"

[Ivan Sagalaev]

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 because you conveniently get a queryset from a related 
manager. In other words, `topic.article_set.all()` should always yield 
the same data as `Article.objects.filter(topic=topic)`.


But I would agree that in this case:


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 by 
default while allowing other uses if needed.


--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #14891, a.k.a. "related managers don't work how we claim they do"

[Luke Plant]

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 deprecation path for the
> current behavior)?

I vote for A - fix the bug.

Luke



-- 
"In my opinion, we don't devote nearly enough scientific research
to finding a cure for jerks." (Calvin and Hobbes)

Luke Plant || http://lukeplant.me.uk/

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Filter via related_name in inherited model not working .. Bug?

[Carl Meyer]

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 see any evidence of a bug in Django here (we've got
a pretty good test suite for filter traversal and inheritance), so this
thread should move to django-users.

Carl

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Accidental logging disabling

[Carl Meyer]

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 settings
>> print 'Used %s' % (datetime.now() - start)
>>
>> You might get weird results as accessing settings can change your
>> timezone. Would it be wise that setup_environ() would access the
>> settings so that they are no more lazy? Or does this cause other
>> problems?
> 
> I didn't have in mind changing the settings object to be non-lazy. It
> looks like a rather intrusive change. And I can't really predict
> consequences. 

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 when certain functionality is
used).

I do, however, think that it would be fine to have the setup_environ
function explicitly trigger settings-loading. This should never be a
problem, because setup_environ already sets DJANGO_SETTINGS_MODULE. It's
also not an invasive change at all - it should be a one-liner, I think.

My gut feeling tells me that changing things from being
> immediate to be lazy is the source of many hidden problems. But it
> should be safe vice versa because if the environment already works with
> a lazy object it couldn't count on the order of execution. So immediate
> instantiation shouldn't break the logic. What it could do though is
> affect performance…

I don't think there would be any performance issues. Any code that's
calling setup_environ is quite likely accessing settings not long
thereafter, so it would shift a rather small bit of work that would
happen anyway to happen sooner rather than later.

> Anyway I still think strongly suggesting not disabling existing loggers
> would suffice.

That might be reasonable as well - I'm interested to hear Russell speak
to that, as he did the logging work. I still think making setup_environ
non-lazy is a reasonable change that will address a broader range of
problems.

Carl

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: The model option's verbose_name_raw is not really that 'raw'

[Viktor Kojouharov]

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 from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: The model option's verbose_name_raw is not really that 'raw'

[Carl Meyer]

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_name' would already be translated, provided that the
> user wrote the meta option as "verbose_name = _('Some name')"

That depends on what "_" is in the relevant models.py. If it is one of
the lazy variants (i.e. "django.utils.translation.ungettext_lazy") [1],
which it should be, then the verbose_name is not translated until it is
coerced to unicode, and the definition of the verbose_name_raw property
is correct.

If you use a non-lazy translation function for your verbose_name, it
almost certainly won't work as expected at all, because it will be
translated once when your models.py is imported and not translated to
the appropriate locale for each user.

Carl


  [1] see
http://docs.djangoproject.com/en/1.3/topics/i18n/internationalization/#lazy-translation

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

A monthly Django session in Leicester with guest speakers on set topics - would this be of interest to you?

[Leon]

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 presentation from a guest speaker and a chance
to chat about it afterwards.

We're just trying to gauge the level of interest at the moment to see
if there are enough Django developers around Leicester to make it
worthwhile, if this is something that you would be interested in
attending then let me know!

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

The model option's verbose_name_raw is not really that 'raw'

[Viktor Kojouharov]

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 wrote the 
meta option as "verbose_name = _('Some name')"

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: DDN: #2594 (Template system whitespace) may cause blocktrans issue

[Jonathan Slenders]

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 the actual output.) I understand
that in most cases, it's ugly to have the indentation and leading/
trailing whitespace in the msgid, but it's not always appropriate to
strip these whitespace characters.

Personally, I prefer more explicit whitespace control [1].

Anyway, I don't know much about this subject

[1] http://jinja.pocoo.org/docs/templates/#whitespace-control

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Filter via related_name in inherited model not working .. Bug?

[robim42]

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)
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/alex/alex/django-1.2.x/django/db/models/manager.py",
line 141, in filter
return self.get_query_set().filter(*args, **kwargs)
  File "/Users/alex/alex/django-1.2.x/django/db/models/query.py", line
561, in filter
return self._filter_or_exclude(False, *args, **kwargs)
  File "/Users/alex/alex/django-1.2.x/django/db/models/query.py", line
579, in _filter_or_exclude
clone.query.add_q(Q(*args, **kwargs))
  File "/Users/alex/alex/django-1.2.x/django/db/models/sql/query.py",
line 1170, in add_q
can_reuse=used_aliases, force_having=force_having)
  File "/Users/alex/alex/django-1.2.x/django/db/models/sql/query.py",
line 1058, in add_filter
negate=negate, process_extras=process_extras)
  File "/Users/alex/alex/django-1.2.x/django/db/models/sql/query.py",
line 1237, in setup_joins
"Choices are: %s" % (name, ", ".join(names)))
FieldError: Cannot resolve keyword 'partner' into field. Choices are:
buyer, buyer_partner, id, item_owner, name, seller

Which lead me to the conclusion that I have to use buyer_partner (the
related name) to get what I want (which is: all Items which habe been
bought by any buyer having partner s as a partner).

If I do a print query on the original filter, I get the following,
which seems not right to me:

>>> print Item.objects.filter(owner__buyer_partner = s).query
SELECT "multi_item"."id", "multi_item"."name", "multi_item"."owner_id"
FROM "multi_item" INNER JOIN "multi_base" ON ("multi_item"."owner_id"
= "multi_base"."id") INNER JOIN "multi_buyer" ON ("multi_base"."id" =
"multi_buyer"."partner_id") WHERE "multi_buyer"."base_ptr_id" = 2


Regards

Alex

On Apr 15, 5:01 pm, Carl Meyer  wrote:
> Hi Alex,
>
> On 04/15/2011 07:51 AM, robim42 wrote:
>
>
> > --- models.py code --- snip ---
> > from django.db import models
>
> > class Base(models.Model):
> >     name = models.CharField(max_length=20)
>
> >     def __unicode__(self):
> >         return self.name
>
> > class Seller(Base):
> >     childa = models.CharField(max_length=20)
>
> >     def __unicode__(self):
> >         return u'%s: %s' %(self.name, self.childa)
>
> > class Buyer(Base):
> >     childb = models.CharField(max_length=20)
> >     partner = models.ForeignKey(Base, related_name = 'buyer_partner',
> > blank = True, null = True)
>
> >     def __unicode__(self):
> >         return u'%s: %s, %s' %(self.name, self.childb, self.partner)
>
> > class Item(models.Model):
> >     name = models.CharField(max_length=20)
> >     owner = models.ForeignKey(Base, related_name='item_owner',
> > blank=True, null=True)
>
> >     def __unicode__(self):
> >         return u'%s: %s' %(self.name, self.owner)
> > --- snap ---
>
> > I'm using postgresql in the real application and the sqlite3 backend
> > on this example here, both behave the same.
> > To add some data I do the following on the python shell (python manage
> > shell):
> > --- snip ---
>  from multi.models import Seller, Buyer, Item, Base
>  seller = Seller(name='Seller1', childa='ChildA')
>  seller.save()
>  buyer = Buyer(name='Buyer1', childb='ChildB', partner=seller)
>  buyer.save()
>  item = Item(name='Nice Thing', owner = buyer)
>  item.save()
>
> > --- snap ---
>
> > After this I do some query to verify that everything is in the
> > database (also on the shell):
> > --- snip ---
>  from multi.models import Seller, Buyer, Item, Base
>  Buyer.objects.all()
>
> > []
>  Seller.objects.all()
>
> > []
>  Item.objects.all()
>
> > []
> > --- snap ---
>
> > So all necessary data is in the database ... now a few queries to get
> > data back out and assigned to some vars ... and finally to filter
> > queries ... the first one is working, the second one seems to bee
> > 'broken' (gives no result = []) and I don't know why ...
> > --- snip ---
>  from multi.models import Seller, Buyer, Item, Base
>  s = Seller.objects.get(name='Seller1')
>  b = Buyer.objects.get(name='Buyer1')
>  s
>
> > 
>  b
>
> > 
>  Item.objects.filter(owner=b)
>
> > []
>  Item.objects.filter(owner__buyer_partner = s)
>
> > []
> > --- snap ---
>
> > Could anyone point me to the right direction or give me an example how
> > it is supposed to work?
>
> If I'm reading this right, I think you're misunderstanding which side of
> the relationship related_name applies to. The way you have your models
> set up, "buyer_partner" is the name you would use to traverse from the
> partner targeted by the "partner" FK back to the Buyer containing that
> FK. To traverse from the Buyer to its partner, you would just use
> "partner" (the name of the FK) not