python–manytomany关系不存在.它处于不同的架构中

概述我将AbstractBaseUser与CustomPermissionsMixin一起使用.CustomPermissionsMixin与django PermissionsMixin相同,不同之处在于我为user_permissions和groups更改了related_name和related_query_name,因此它不会与django Permis

我将AbstractBaseUser与CustomPermissionsMixin一起使用.
CustomPermissionsMixin与django PermissionsMixin相同,不同之处在于我为user_permissions和groups更改了related_name和related_query_name,因此它不会与django PermissionsMixin related_name冲突

@python_2_unicode_compatibleclass CustomPermissionsMixin(models.Model):    """    A mixin class that adds the fIElds and methods necessary to support    Django's Group and Permission model using the ModelBackend.    """    is_superuser = models.BooleanFIEld(        _('superuser status'),default=False,help_text=_(            'Designates that this user has all permissions without '            'explicitly assigning them.'        ),)    groups = models.ManyToManyFIEld(        Group,verbose_name=_('groups'),blank=True,help_text=_(            'The groups this user belongs to. A user will get all permissions '            'granted to each of their groups.'        ),related_name="%(app_label)s_%(class)s_related",related_query_name="%(app_label)s_%(class)ss",)    user_permissions = models.ManyToManyFIEld(        Permission,verbose_name=_('student user permissions'),help_text=_('Specific permissions for this user.'),)    class Meta:        abstract = True    ....

我在两个不同的应用程序中拥有相同的Student类.一个在App1中,另一个在App2中,字段略有不同.我用postgresql. App1处于架构公共状态,而App2处于架构krt5jdjtrx.(使用django tenant schema.以编程方式创建)两者都使用AbstractBaseUser和CustomPermissionsMixin

class Student(AbstractBaseUser,CustomPermissionsMixin):    ...

我也使用DRF DjangoModelPermissions

REST_FRAMEWORK = {    'DEFAulT_PERMISSION_CLASSES': (        'rest_framework.permissions.IsAuthenticated','rest_framework.permissions.DjangoModelPermissions',

和自定义身份验证后端

class CustomBackend(ModelBackend):    ....

问题出在django ModelBackend中的_get_user_permissions.假设user_obj的类型为app1.Student,user_obj.user_permissions.all().查询有时使用app1_student_user_permissions或app2_student_user_permissions.为什么user_obj确实是app1而不是app2,为什么查询使用app2_student_user_permissions？ .它会创建django.db.utils.ProgrammingError：关系不存在.

def _get_user_permissions(self,user_obj):    print('insIDe _get_user_perm !!!!!!!!!!!!!!!!!!!!!!!')    print(user_obj)    print(type(user_obj))    print(user_obj.user_permissions.all().query)    return user_obj.user_permissions.all()

这是原始查询集

SELECT "auth_permission"."ID","auth_permission"."name","auth_permission"."content_type_ID","auth_permission"."codename" FROM "auth_permission" INNER JOIN "app2_student_user_permissions" ON ("auth_permission"."ID" = "app2_student_user_permissions"."permission_ID") INNER JOIN "django_content_type" ON ("auth_permission"."content_type_ID" = "django_content_type"."ID") WHERE "app2_student_user_permissions"."student_ID" = 1 ORDER BY "django_content_type"."app_label" ASC,"django_content_type"."model" ASC,"auth_permission"."codename" ASC

编辑

App2学生的模式/表格将在稍后的程序中创建.
由于App2学生与权限有很多关系,因此权限现在具有app1关系和app2关系.我认为它是由ManyRelatedManager注册的. (权限将这两个关系视为公共架构)

如果我执行student1_of_app1.user_permissions.all(),Django将遍历Permissions所具有的关系.包括不存在的App2表.因此它会创建django.db.utils.ProgrammingError：关系不存在.

但是,有时没有错误,因为Django首先进入app1关系,但有时Django进入app2关系,因此错误.

我怎样才能防止这种情况发生？

最佳答案我发现问题是关于django租户架构而不是django.无论应用程序是共享还是租户,migrate_schema –shared实际上都会迁移整个makemigration文件.这两个应用程序(共享和租户)都在django_content_type表中注册,该表也在auth_permissions中注册.因此,该关系不存在,因为此时尚未创建租户表,但已为权限注册了许多关系. 总结

以上是内存溢出为你收集整理的python – manytomany关系不存在.它处于不同的架构中全部内容，希望文章能够帮你解决python – manytomany关系不存在.它处于不同的架构中所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。