Looking for the right way to specialize the User model

[Paul Whipp]

I'm using Django 1.5 and I needed an api to control the addition of users 
and the management of users on those groups. Django's rest framework proved 
a good starting point but I hit issues with the ManyToMany relation groups 
which means that there is no model for the user_group which in turn 
complicated the API. I worked around this fairly easily with the following 
code:

from django.db import models
from django.contrib.auth.models import User, UserManager, Group

class UserGroup(models.Model):
user = models.ForeignKey(User)
group = models.ForeignKey(Group)
class Meta:
# auth_user_groups is created by the ManyToMany relation field
# in the contrib.auth.models User model
managed = False
db_table = 'auth_user_groups'

# Add an easy way to get at this from the User objects
def get_user_groups(self):
return UserGroup.objects.filter(user=self)
User.add_to_class('get_user_groups', get_user_groups)

This handles the problem by allowing the API to have convenient usergroup 
urls and endpoints but I don't like using 'add_to_class'. I really just 
want a specialized user class but I could not get the following to work:

class APIUser(User):
objects = UserManager()
class Meta:
managed = False
db_table = 'auth_user'

def get_user_groups(self):
return UserGroup.objects.filter(user=self)

Sadly, it fails with, for example, "Unknown column 'auth_user.user_ptr_id' 
in 'where clause'" if I try to save a newly created APIUser.

Am I barking up the wrong tree or just missing something obvious?


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Inconsistent Django test results depending upon how the test is called in Django 1.5.1 running on Python 2.7.4

[Paul Whipp]

I have test cases that pass when tested individually, pass when the full 
app is tested but fail when the tests for the entire project are run:

(lsapi)~ $ django test
Creating test database for alias 'default'...
.s.x..Exception
 RuntimeError: 'maximum recursion depth exceeded' in  ignored
Exception RuntimeError: 'maximum recursion depth exceeded' in  ignored
Exception RuntimeError: 'maximum recursion depth exceeded' in  ignored
...ssE.E.E.Setting
 content_object to liquid app one
.EEE....
==
ERROR: test_get_direct_notes (lsapi.tests.DirectGetTestCase)
--
Traceback (most recent call last):
  File "ls-api/lsapi/tests.py", line 869, in _method

  File "ls-core/lscore/model/note.py", line 37, in company
return self.content_object.company
AttributeError: 'NoneType' object has no attribute 'company'
...


(lsapi)~ $ django test lsapi.NotesTestCase.test_wrong_user_cannot_put
Creating test database for alias 'default'...
.
--
Ran 1 test in 0.241s

OK
Destroying test database for alias 'default'...


(lsapi)~ $ django test lsapi
Creating test database for alias 'default'...
...ss..Setting
 content_object to liquid app one
...Exception RuntimeError: 'maximum recursion depth exceeded 
while calling a Python object' in <_ctypes.DictRemover object at 0x46dac70> 
ignored
.
--
Ran 303 tests in 71.469s

OK (skipped=2)
Destroying test database for alias 'default'...

The 'django' command is an alias for django-admin.py. So the tests pass if 
run as a single case or as a test suite when testing the entire app but 
fail with errors if run when running the tests for all of the apps in the 
project.

Investigating the error in the full suite test: It is the result of an 
attribute being None when it 'should' have a value. The attribute is a 
content_object set up in a fixture.

I added a debugging setattr on the class and nothing is setting it to None 
so it seems that the fixture code is not being properly executed to set up 
the object leading to the errors. The fixture is using content types 
because it is for 'notes' that can be associated with various model classes:

notes.py:

...
class Note(TimeStampedModel):
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
content_object = generic.GenericForeignKey('content_type', 'object_id')
...
def __setattr__(self, key, value):
if key == 'content_object':
if value is None:
import pdb; pdb.set_trace()
print('Setting content_object to {0}'.format(value))
return super(Note, self).__setattr__(key, value)

local_test.json:

...
 {"pk": 1, "model": "lscore.note",
  "fields": {"content_type": 16,
 "object_id": 2,
 "created_by": 4,
 "text": "This is the note text"}},
...

Thinking on this further, GenericForeignKey is likely to work by accessing 
the content_type/object_id fields and the fixtures code will be responsible 
for putting these directly into the database. On this basis, I trapped the 
error and investigated the database at the point when it occurred in the 
full suite test. Sure enough, the content object has not been set in the 
test database when the error occurs. The above fixture works fine in the 
other test invocations and all of the fixtures are in a single file which 
is the only fixtures file specified and loaded for the test case.

Looking at the recursion errors which only occur on the full suite testing 
and which might conceivably have something to do with this, I added 
sys.setrecursionlimit(3000) to the relevant tests.py file. This eliminated 
the recursion errors but had no effect on the test errors describe

Re: python virtual environment

[Paul Whipp]

Looks like you already have an active virtual environment but those 
instructions only install a few default things (like Django) into that 
environment.

Therefore it sounds like your new virtual environment does not have all of 
the required python modules installed in it.

There should be a requirements.txt file or similar associated with the 
project which you can use for the purpose with pip. See 
herefor more info.

On Sunday, 1 December 2013 12:13:28 UTC+10, Avraham Serour wrote:
>
> you need to activate the virtualenv before using:
> on windows:
> env\Scripts\activate
> on linux:
> source env/bin/activate
>
>
> On Fri, Nov 29, 2013 at 7:44 PM, tino >wrote:
>
>>
>>
>> Hello
>>
>> I am trying to run a project that was setup in another server, but 
>> getting the following error. I am using python 2.7, django, virtualenv. So 
>> I am running the project inside a python virtual environment
>>
>>
>> (virtualenv)[web.srv1 daily# python manage.py runserver 0.0.0.0:8000
>> Traceback (most recent call last):
>>   File "manage.py", line 2, in 
>> from django.core.management import execute_manager
>> ImportError: cannot import name execute_manager
>>
>>
>> I used the method mentioned in the below link to setup the virtual 
>> environment.
>>
>> http://toic.org/blog/2011/wsgi-on-cpanel-improved/
>>
>> This project was setup inside a cpanel server. But the current server I 
>> using is not a cpanel server. It is normal centos server.
>>
>> Can somebody help me to track down the issue.
>>
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/7181ba64-d2d6-4926-b35d-5b4a2a7792a4%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/289a11a7-1cf7-40e0-adc1-aa6d6a89a338%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Inconsistent Django test results depending upon how the test is called in Django 1.5.1 running on Python 2.7.4

[Paul Whipp]

Hi Russ,

Thanks for your detailed response, deserving of this detailed investigation:

I eventually found that it is the simple declaration of a model within the
test suites that is causing the problem:

django.contrib.contents.tests causes the problem - even if I removed all of
the tests and just imported the file:

I copied and pared the file down to this which still causes the error:

from django.db import models


class ConcreteModel(models.Model):
name = models.CharField(max_length=10)


class ProxyModel(ConcreteModel):
class Meta:
proxy = True

If I remove the ProxyModel class the error changes and becomes a recursion
depth error.

Renaming the classes does not get rid of the error (and the class names are
not used in my apps).

The infinite recursion problem feels somehow related. My models do do
something unusual: Much of the application revolves around models belonging
to a company so, for convenience, all models have a company property that
returns the company that owns them - it often does this by referencing
objects on it. In the case of a company, the company property returns self.
In the case of a note (the model where we're getting this problem), the
content_object is a company and the note's company method accesses its
content_object company attribute:

class Note(TimeStampedModel):
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
content_object = generic.GenericForeignKey('content_type', 'object_id')
...

@property
def company(self):
return self.content_object.company

class Company(BaseModel, ModelWithRandomisedToken):
...

@property
def company(self):
return self

I think this is progress. Declaring ANY model class within the test suite
causes the infinite recursion issue on the access. So my theory is that
something in the django caching somewhere is getting partly updated when
the model is declared but not fully sorted so the caches are broken with
respect to content types. This has two symptoms - object references being
None and infinite recursion, depending upon how the error gets encountered.

I'm guessing that there is some 'tidying up' of content types after all the
models are imported that does not get done for a model arbitrarily defined
in the test suite.

Does it sound like I am going in the right direction?

Thanks again for your help.

Cheers, Paul


On 2 December 2013 11:10, Russell Keith-Magee wrote:

>
>
> On Mon, Dec 2, 2013 at 8:24 AM, Paul Whipp  wrote:
>
>> I have test cases that pass when tested individually, pass when the full
>> app is tested but fail when the tests for the entire project are run:
>>
>> (lsapi)~ $ django test
>> Creating test database for alias 'default'...
>> .s.x..Exception
>>  RuntimeError: 'maximum recursion depth exceeded' in > 0x13447d0> ignored
>> Exception RuntimeError: 'maximum recursion depth exceeded' in > remove at 0x13447d0> ignored
>> Exception RuntimeError: 'maximum recursion depth exceeded' in > remove at 0x13447d0> ignored
>> ...ssE.E.E.Setting
>>  content_object to liquid app one
>> .EEE....
>> ==
>> ERROR: test_get_direct_notes (lsapi.tests.DirectGetTestCase)
>> --
>> Traceback (most recent call last):
>>   File "ls-api/lsapi/tests.py", line 869, in _method
>> 
>>   File "ls-core/lscore/model/note.py", line 37, in company
>> return self.content_object.company
>> AttributeError: 'NoneType' object has no attribute 'company'
>> ...
>>
>>
>> (lsapi)~ $ django test lsapi.NotesTestCase.test_wrong_user_cannot_put
>> Creating test database for alias 'default'...
>> .
>> --
>> Ran 1 test in 0.241s
>>
>> OK
>> Destroyi

Re: Django Channels - core.py error

[Paul Whipp]

I've just had trouble with exactly the same error. In my case I was 
building from the tutorial ChatConsumer with my own XChatConsumer and I 
hadn't referenced it in the routing.py. As a result the tutorial async chat 
consumer was receiving a scope that did not contain a room_name in its 
url_route kwargs. Very obscure! I think the channel gets closed by an error 
and then this 500 error comes up rather than anything helpful for the 
original error.

On Friday, 12 October 2018 07:06:13 UTC+10, itsnate_b wrote:
>
> Hi Simon,
>
> Sorry to hear that you are having the same problem! Channels can be a 
> blessing and a curse. I find it very finicky with very poor documentation & 
> poor error handling. As for the fix: I had an AsyncWebsocketConsumer class 
> in consumers.py within which I had a custom __init__ function. I believe I 
> was setting the scope incorrectly within the init. I realized that I had no 
> need to override/augment the init and removed it. The result was that the 
> error disappeared. That was it for me. I have since updated to all the 
> latest builds for the channels & redis infrastructure.
>
> Hope that helps.
>
> Cheers,
> Nathan
>
> On Tuesday, October 9, 2018 at 9:59:33 AM UTC-4, Simon Vézina wrote:
>>
>> Hi itsnate_b,
>>
>> Would you mind elaborating on your fix?
>>
>> I'm getting this exact error and I'm at a complete loss.   Everything 
>> works fine in local, but on my live server, after a couple of minutes/hours 
>> of working fine, I start getting this error in the logs.
>>
>> Thanks!
>>
>> Le dimanche 2 septembre 2018 13:26:29 UTC-4, itsnate_b a écrit :
>>>
>>> Turns out there was an erroneous *init* function in the 
>>> AsyncWebsocketConsumer class. Removing it fixed the issue.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e1ebd5c9-5326-4d03-9512-f6f1deec28a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.