DjangoAdminの重大なパフォーマンスの問題-外部キーラベル

Rach Odwyer

DjangoAdminで重大なパフォーマンスの問題が発生しています。

他の2つのモードの主キーをマッピングするマッピングモデルがあります

FundManagerMappingAdminで、2つのテーブルの外部キーを外部キーモデルのラベルで表現しようとしています。

基礎となるモデルは約4000行です

adminでリストを取得するとき、および編集と更新を行うときにパフォーマンスが低下します

誰かがこのコードの非効率性を指摘してもらえますか?

もっと良い方法はありますか?

Admin.py

@admin.register(ChampDwDimFundManagerMapping)
class FundManagerMappingAdmin(admin.ModelAdmin):

list_display = ['get_champ_fund_manager_id', 'get_evestment_name', 'get_sharepoint_name', ]

def get_champ_fund_manager_id(self, obj):
    return obj.fund_manager_id
get_champ_fund_manager_id.short_description = 'CHAMP Manager ID'

def get_evestment_name(self, obj):
    return obj.evestment_fund_manager_id.manager_name
get_evestment_name.short_description = 'Evestment Manager Name'

def get_sharepoint_name(self, obj):
    return obj.sharepoint_fund_manager_id.manager_name
get_sharepoint_name.short_description = 'Sharepoint Manager Name'

def get_form(self, request, obj=None, **kwargs):
    form = super(ChampFundManagerMappingAdmin, self).get_form(request, obj, **kwargs)
    form.base_fields['sharepoint_fund_manager_id'].label_from_instance = lambda obj: "{} {}".format(obj.final_publications_fund_manager_id, obj.manager_name)
    form.base_fields['evestment_fund_manager_id'].label_from_instance = lambda obj: "{} {}".format(obj.evestment_fundmanager_id_bk, obj.manager_name)
    return form

Models.py

class FundManagerMapping(models.Model):
    fund_manager_id = models.AutoField(db_column='FundManagerId', primary_key=True)  
    sharepoint_fund_manager_id = models.ForeignKey(SharePointFundManager, models.DO_NOTHING, db_column='SharePointFundManagerId')  
    evestment_fund_manager_id = models.ForeignKey(EvestmentFundManager, models.DO_NOTHING, db_column='eVestmentFundManagerId')  

class EvestmentFundManager(models.Model):
    evestment_fund_manager_id = models.AutoField(db_column='eVestmentFundManagerId', primary_key=True)  
    package_execution_id = models.IntegerField(db_column='PackageExecutionId')  
    evestment_fund_manager_id_bk = models.CharField(db_column='eVestmentFundManagerId_BK', max_length=50)  
    manager_name = models.CharField(db_column='ManagerName', max_length=255)  

class SharePointFundManager(models.Model):
    sharepoint_fund_manager_id = models.AutoField(db_column='SharePointFundManagerId', primary_key=True)  
    package_execution_id = models.IntegerField(db_column='PackageExecutionId')  
    research_fund_manager_id = models.CharField(db_column='ResearchFundManagerId', max_length=50, blank=True, null=True)  
    final_publications_fund_manager_id = models.CharField(db_column='FinalPublicationsFundManagerId', max_length=50, blank=True, null=True)  
    manager_name = models.CharField(db_column='ManagerName', max_length=255)  
trixn

あなたは、表示されているname関連するエンティティ(のためのget_evestment_name、およびget_sharepoint_nameそれらをプリフェッチ/参加せず)を。つまり、表示するすべての行と関連するエンティティのすべての名前について、データベースクエリを作成するためにdjangoが必要です。をオーバーライドget_queryset()し、ModelAdminを使用select_relatedしてdjangoに最初からこれらのエンティティに参加するように指示して、これらの名前を取得するために追加のクエリを必要としないようにする必要があります。

@admin.register(ChampDwDimFundManagerMapping)
class FundManagerMappingAdmin(admin.ModelAdmin):
    def get_queryset(self, request):
        return super().get_queryset(request).select_related(
            'sharepoint_fund_manager_id', 
            'evestment_fund_manager_id',
        )

また、ForeignKeyフィールドに名前を付けませんsomething_idこれはsharepoint_fund_manager呼び出したときに取得するのがfund_manager.sharepoint_fund_manager_idIDではなくのインスタンスであるためSharePointFundManagerです。と呼ぶのは変sharepoint_fund_manager_id.nameです。IDにはname属性がありません。ファンドマネージャーは持っています。

さらにsharepoint_fund_manager_id、フィールドsharepoint_fund_manager呼び出してプレーン外部キーにアクセスすると、Djangoは自動的にプロパティ作成します

この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。

侵害の場合は、連絡してください[email protected]

編集
0

コメントを追加

0

関連記事

分類Dev

シミュレーションの反復に伴う重大なパフォーマンスの問題

分類Dev

配列をパラメーターとして使用すると、どの演算子にも重大なパフォーマンスの問題があります

分類Dev

パフォーマンスの問題

分類Dev

選択可能なRecyclerViewのパフォーマンスの問題

分類Dev

yaml-cppの主なパフォーマンスの問題

分類Dev

DataReaderのパフォーマンスの問題、奇妙な動作

分類Dev

奇妙なKinecticjsのパフォーマンスの問題

分類Dev

ベクトルのパフォーマンスの問題

分類Dev

予期しないパフォーマンスの問題

分類Dev

外部 IO のパフォーマンスの問題?

分類Dev

Rのループのパフォーマンスの問題

分類Dev

ループ内のjQueryパフォーマンスの問題

分類Dev

カーソルのパフォーマンス低下の問題

分類Dev

HDDCドライブのパフォーマンスの問題

分類Dev

春の起動時のパフォーマンスの問題

分類Dev

matplotlibの凡例のパフォーマンスの問題

分類Dev

PageStorageKeyでのFlutterListViewのパフォーマンスの問題

分類Dev

VirtualBoxでのLinuxMintのパフォーマンスの問題

分類Dev

Burrows-PythonのWheelerのパフォーマンスの問題

分類Dev

Djangoの多対多のパフォーマンスの問題

分類Dev

SQLでのUNION句のパフォーマンスの問題

分類Dev

Where andContainsでのLINQtoEntitiesのパフォーマンスの問題

分類Dev

HikariCP での Postgresql のパフォーマンスの問題

分類Dev

Springの@Autowiredは大きなパフォーマンスの問題ですか?

分類Dev

Coldfusion10で再現可能なCFQUERYPARAMのパフォーマンスの問題

分類Dev

奇妙なJavaScript / Node.jsのパフォーマンスの問題

分類Dev

SQLServerクエリの断続的なパフォーマンスの問題

分類Dev

単純なクエリでのパフォーマンスの問題

分類Dev

NestJsテストのパフォーマンスの問題

Related 関連記事

  1. 1

    シミュレーションの反復に伴う重大なパフォーマンスの問題

  2. 2

    配列をパラメーターとして使用すると、どの演算子にも重大なパフォーマンスの問題があります

  3. 3

    パフォーマンスの問題

  4. 4

    選択可能なRecyclerViewのパフォーマンスの問題

  5. 5

    yaml-cppの主なパフォーマンスの問題

  6. 6

    DataReaderのパフォーマンスの問題、奇妙な動作

  7. 7

    奇妙なKinecticjsのパフォーマンスの問題

  8. 8

    ベクトルのパフォーマンスの問題

  9. 9

    予期しないパフォーマンスの問題

  10. 10

    外部 IO のパフォーマンスの問題?

  11. 11

    Rのループのパフォーマンスの問題

  12. 12

    ループ内のjQueryパフォーマンスの問題

  13. 13

    カーソルのパフォーマンス低下の問題

  14. 14

    HDDCドライブのパフォーマンスの問題

  15. 15

    春の起動時のパフォーマンスの問題

  16. 16

    matplotlibの凡例のパフォーマンスの問題

  17. 17

    PageStorageKeyでのFlutterListViewのパフォーマンスの問題

  18. 18

    VirtualBoxでのLinuxMintのパフォーマンスの問題

  19. 19

    Burrows-PythonのWheelerのパフォーマンスの問題

  20. 20

    Djangoの多対多のパフォーマンスの問題

  21. 21

    SQLでのUNION句のパフォーマンスの問題

  22. 22

    Where andContainsでのLINQtoEntitiesのパフォーマンスの問題

  23. 23

    HikariCP での Postgresql のパフォーマンスの問題

  24. 24

    Springの@Autowiredは大きなパフォーマンスの問題ですか?

  25. 25

    Coldfusion10で再現可能なCFQUERYPARAMのパフォーマンスの問題

  26. 26

    奇妙なJavaScript / Node.jsのパフォーマンスの問題

  27. 27

    SQLServerクエリの断続的なパフォーマンスの問題

  28. 28

    単純なクエリでのパフォーマンスの問題

  29. 29

    NestJsテストのパフォーマンスの問題

ホットタグ

アーカイブ