光プロジェクト---問題のいくつかは、バックエンドのインターフェイスを実装する際に遭遇

ImproperlyConfigured：WSGIアプリケーション「lightapi.wsgi.application」をロードできませんでした。

Plusのcorsheaders.middleware.CorsMiddleware '、しかし、このアプリは、（実際には、インストールされていません）上記に登録されていない、それは後のコメントで、あなたはmoddlewareで実行することができます
アプリケーションの作成プロセス：

仮想環境でのアプリケーションの実行Pythonのmanage.py startappの名

--- >>> settings.pyにアプリケーションを登録---- >>> URL内経路（主経路と副経路）を作成

- >>> models.pyテーブルに組み込まれて - このアプリケーションでは、レジストリのモデルを、> adminx.pyファイルを作成するには、グローバル設定を構成

- >>> --- xadminで__init__.py default_app_config = "home.apps.HomeConfig" ディスプレイに配置され

名前のカスタム名を設定=「マイホーム」をverbose_name設定したバックオフィスシステムのサイドバーの応用--- >>> apps.py

--- >>> views.py書き込みビュー機能

---- >>>クラス・シーケンス提供serializers.py
ModuleNotFoundError：いいえアプリを作成した後で「アプリの名前のモジュール、データの移行は、この間違ったことを報告しました

環境変数に追加このフォルダのアプリへのパスを見つけられませんでしたdev.py（設定開発環境）を確認してください
例外RuntimeError：Modelクラスlightapi.apps.home.models.Bannerは、明示的なapp_labelを宣言していないし、内のアプリケーションではありませんん
INSTALLED_APPS。

各apps.pyそれは形而上学で、問題を示していないデータベースを移行し、ファイルを再書き込み、および

同時に、輸入パッケージパスの問題に注意を払います

オンラインで07.28チェックが、それは相対パスに絶対パスで、それができる - 発見後のご質問のうち、今日は少しも変わって>、実際に与えられていません
WARNING basehttp 154「POST /ユーザー/ログイン/モバイル/ HTTP / 1.1」のコードの403 58ログ遠位部、SMSの確認コードを使用して、エラーを返します！
django.db.utils.InternalError：（1050、 "テーブル 'light_news_category' は既に存在します"）

最初の実行：のpython manage.pyは--fakeを移行

再び実行します：python manage.pyの移行を
__str__返された非文字列（int型）

ORMテーブルは、行のRIDリターン・パラメータを取得__str__
django.db.utils.ProgrammingError：（1146、 "テーブル 'light.light_news_recommend' が存在しません"）

https://blog.csdn.net/weisubao/article/details/77187876
django.db.utils.InternalError：（1060、 "重複した列名 'のarticle_id'"）
```
 忘记写如何解决的了
```
WARNING basehttp 154「POST /ユーザー/登録/モバイル/ HTTP / 1.1」つまり、なぜ403 58バックエンドのルーティング機能が正常である、知らない、403

ソリューション：通常の状態に、[]可能=ターゲットビュークラスauthentication_classesに追加

ListAPIViewを使用して記事を取得するが、その後、すべてのデータは、従来のテーブルを取得するために使用され、その後、ここで行う方法がわからない必要性についてすべてのコメント、

その後、ソースコードをいじくりget_queryset方法、書き換えを考え出すのに長い時間が経過した後、彼は内部の文書番号のフロントエンド上を通過し、成功したゴールの後、データベースを照会するためにSQLコードを変更してしまった,,,

--->ちょうどあなたがself.requestああ、そう必要は内部get_querysetで動作しないように取得することができ、私は直接、initメソッドをオーバーライドしたクラスにすることはできません、と思いますが、クラス内の直接インスタント考え、（ - >理由の方法やテクニックかもしれOKではない、それを試してみました）self.requestではありませんが、静的プロパティに設定されて@propertyを設定することができればと思いました

幸いなことに、実現可能な方法を見つけます
```
    def __init__(self, *args, **kwargs):
        super().__init__()
        self.article_id = ''

    def get_queryset(self):
        ..占地方，就删掉了，实际不能删...

        queryset = self.queryset
        from django.db.models.query import QuerySet
        if isinstance(queryset, QuerySet):
            self.article_id = self.request.query_params.get("article_id")  # ---------------------
            # Ensure queryset is re-evaluated on each request.
            queryset = queryset.filter(article_id=self.article_id, is_show=True)  # --改的这一条--------------
        return queryset
```
なぜデータを作成し、外部キーは、int型のビットすることはできません（またはSTRを、その数でなければならない）、およびいくつかは（fiterデータをチェックしてください）データベースクエリ利用可能なデータを持っていますか？
```
例如：ValueError: Cannot assign "2": "Comment.user" must be a "User" instance.（comment字段关联user表）
```

そして、テーブルファンは懸念している：「FansAndのためのリバースアクセサと「FansAndObserved.user」の衝突のためのリバースアクセサ
Observed.observed」。

HINT: Add or change a related_name argument to the definition for 'FansAndObserved.observed' or 'FansAndObserved.user'.

我估计是因为我一张表中同时两个字段关联了同一张表，而且设置的是foreiginKey ，是否需要设置成manytomany才行？

---> 需要关联字段  related_name= ""  ---》 Direct assignment to the reverse side of a related set is prohibited. Use mobile.set() instead.

最终实现结果： related_name= ""  定义的是字段名称，不要和user表里面的字段重复即可 

推测 ---> 应该是用在表中同时关联某一张表多次时，用related_name来区分关联的多个字段

データベース内の1つのデータを継承するが、このhttp://api.light.cn:8000/user/userinfo/2のように、彼らのアイデアは、フロントが渡され、URLにユーザーIDを追加する必要はありませんRetrieveAPIView HTTP：//api.lightトークンは、retrieveAPIViewの方法でデータベースからのデータの単一片の後に来る次いで対応するユーザIDに裏返しRedisの、およびトークンが、この場合はURLで、そのようなことであるべきです。 CN：8000 /ユーザー/のuserinfo /トークン=？。。。（特定のトークン付き）

---> 去源码中发现，原本URL该写成这样： http://api.light.cn:8000/user/userinfo/(?P(<pk>\d+)) ，原本以为，此处的 pk 是任意定义的，但是在retrieveAPIView继承的GenericAPIView中定义了：

```
# If you want to use object lookups other than pk, set 'lookup_field'.
# For more complex lookup requirements override `get_object()`.
lookup_field = 'pk'
lookup_url_kwarg = None
```

  上面的那个lookup_field 参数就是识别URL中的pk的，下面的lookup_url_kwarg应该是从传过来的参数中获取值，具体源代码在下面：

```
# Perform the lookup filtering.
lookup_url_kwarg = self.lookup_url_kwarg or self.lookup_field
```

然后过滤的条件就是这两个参数决定的，**这两个参数写在  get_object  方法里面**，

----》》》》开始的想法是重写get_object方法，但是，写了半天也没有将过滤条件写出来，于是换了思路

----》》》我去找上一层，其中在 **RetrieveModelMixin** 这个类中有

```
def retrieve(self, request, *args, **kwargs):
    instance = self.get_object()
    serializer = self.get_serializer(instance)
    return Response(serializer.data)
```

仔细看看，发现返回的数据也是在这里面操作的，第二行应该是获取queryset数据了，第三行是序列化，那么我只将第二行的数据注释掉，自己从数据库里面拿数据不就行了嘛，，，

----》》》 实践结果发现，确实拿到了目标数据，并且URL也变成了http://api.light.cn:8000/user/userinfo/?token= 。。。(跟的是具体的token）

これはまだ最適化される、トークン内部のRedisは削除されていない、時間のログアウト

光プロジェクト---問題のいくつかは、バックエンドのインターフェイスを実装する際に遭遇

おすすめ