#19185 closed Uncategorized (worksforme)
AUTH_USER_MODEL and GeoManager
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | |
Severity: | Release blocker | Keywords: | AUTH_USER_MODEL GeoManager |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I'm currently working on getting to run an 1.4-application (using a profile model) on 1.5dev, using the the new (eagerly awaited by me)
custom user model.
I used django.contrib.gis.db.GeoManager with my former profile-Model and so I wanted to use it with my new custom user model, too.
The following exception was thrown:
" 'GeoManager' object has no attribute 'get_by_natural_key' "
Hacking contrib/gis/db/models/manager.py, making GeoManager subclass 'django.contrib.auth.models.UserManager'
instead of 'Manager' solved it for the moment.
Maybe this is something that hasn't been thought of yet.
Change History (4)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Custom user objects require a custom manager that inherits from at least django.contrib.auth.models.BaseUserManager, which defines the get_by_natural_key method
There are a minimum set of documented requirements for a manager of User objects, and GeoManager does not meet that set.
Because the GeoManager defines a completely non-conflicting set of methods - you should be able to define your manager as:
class MyCustomGeoUserManager(BaseUserManager, GeoManager):
and then defining create_user and create_superuser on MyCustomGeoUserManager per the docs
comment:3 by , 12 years ago
Yes, I know how I can solve this.
But shouldn't it be working "out of the box"?
comment:4 by , 12 years ago
That's our point - it *does* work out of the box. However, nothing works "out of the box" if you don't write the correct code for your situation.
We can't make the default UserManager a GeoManager, because not all Users are GIS-enabled. We also can't make the default GeoManager a UserManager -- not all GIS models are Users. The only way we can address this with code would be to provide a "UserGeoManager" -- however, such a class wouldn't be adding any functionality on top of what you can get yourself by subclassing both GeoManager and UserManager. On top of that, we'd then have an additional class to document, which people would have to learn about, and then use correctly.
If you have another approach that we could take to solve this, please let us know.
Can you try creating and using a custom manager inheriting from both GeoManager and UserManager (or BaseUserManager)?