Code

Opened 21 months ago

Closed 21 months ago

Last modified 21 months ago

#19185 closed Uncategorized (worksforme)

AUTH_USER_MODEL and GeoManager

Reported by: email.max.bucher@… 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.

Attachments (0)

Change History (4)

comment:1 Changed 21 months ago by claudep

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Can you try creating and using a custom manager inheriting from both GeoManager and UserManager (or BaseUserManager)?

comment:2 Changed 21 months ago by ptone

  • Resolution set to worksforme
  • Status changed from new to 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 Changed 21 months ago by email.max.bucher@…

Yes, I know how I can solve this.
But shouldn't it be working "out of the box"?

comment:4 Changed 21 months ago by russellm

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.