After more research, I've found out that the problem existed because
of the bug reported in the ticket #2438.
http://code.djangoproject.com/ticket/2438
That is, under certain circumstances, not all the modules where
registered in the application cache.
To solve the problem, I had to eliminate all the initial database
loadings in the models, like:
- lists of ids to limit choices to
- default ids for ForeignKeys retrieved by slugs
- choices for number or text fields when they relate to some database
entries and for some reason they are not ForeignKeys
If you still want to have the default values and specific choices, you
can do the following:
Change this type of usage in models.py files:
DEFAULT_ID = AAA.objects.get(slug="default").id
LIMITED_IDS = [item.id for item in
AAA.objects.filter(**somecomplexfilter)]
CHOICES = [(item.id, item.get_something()) for item in
BBB.objects.filter(**someothercomplexfilter)]
class CCC(models.Model):
aaa = models.ForeignKey(AAA, default=DEFAULT_ID,
limit_choices_to={'id__in': LIMITED_IDS})
some_choice = models.IntegerField(choices=CHOICES)
into
def get_default_id():
return AAA.objects.get(slug="default").id
get_limited_ids():
return [item.id for item in
AAA.objects.filter(**somecomplexfilter)]
class ChoiceListSimulator(object):
def __iter__(self):
return iter([(item.id, item.get_something()) for item in
BBB.objects.filter(**someothercomplexfilter)])
class CCC(models.Model):
aaa = models.ForeignKey(AAA, default=get_default_id,
limit_choices_to={'id__in': get_limited_ids})
some_choice =
models.IntegerField(choices=ChoiceListSimulator())
Regards,
Aidas Bendoraitis [aka Archatas]
On Sep 18, 2:23 pm, "Aidas Bendoraitis" <[EMAIL PROTECTED]>
wrote:
> Hello, django users!
>
> I am experiencing a strange behavior with our Django project on one of
> the development computers.
>
> We have such a situation where Users can be members of one or more
> sharedspaces which are related to institutions.
> User <- Membership -> SharedSpace -> Institution
>
> Lately, I changed the previously used django row-level-permission
> branch to the trunk. After the change, the following query
> user_institutions =
> Institution.objects.filter(sharedspace__membership__user=request.user)
> fails just on one development environment with the error, saying that
> the sharedspace attribute was not found. (All relationships are
> implemented as ForeignKeys)
>
> User is from the auth app
> Institution model resides in the accounts app
> Membership and SharedSpace reside in the groups app
>
> All the apps are listed in the INSTALLED_APPS in the following order:
> 1. django.contrib.auth
> 2. accounts
> 3. groups
>
> However, it still works perfectly on another two development
> computers. The architecture and installation of that computer with the
> strange behavior matches another development environment where it
> works OK.
>
> Has anyone any clues, what could be wrong on that machine or in the code?
>
> Regards,
> Aidas Bendoraitis [aka Archatas]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
