4

私は現在、バックエンドでDjango-Rest-Frameworkを使用し、フロントエンドでEmber.js/Ember-dataを使用するプロジェクトを作成しています。

この形式で、emberアプリからdjangoapiにクエリを返したいと思っています。

http://myurl.com/application/api/model/?parameter=X

ここで、parameterは照会対象のモデルのフィールドであり、Xは検索する値です。

このような大まかなものが結果のクエリになるはずです

queryset = Model.objects.filter(**request.QUERY_PARAMS.dict())

ここで、QUERY_PARAMS.dict()は、次の形式の辞書を提供するDjango構文です。

{parameter:X}

** Djangoが期待するように、dictをキーワード引数に変換します。
したがって、上記の行は事実上次のようになります。

queryset = Model.objects.filter(parameter=X)

私はすでにカスタムビューとカスタムミックスインを使用してこれを機能させていますが、クエリ処理の実装が少し単純である可能性があり、これは非常に一般的なパターンとして私を襲うのではないかと心配しています。

Django用のライブラリがあるのか​​、それともDjangoの内部にあるのか、カスタムクエリセットコードなしでこれらの比較的一般的なクエリを処理できるのか、完全には理解していないのでしょうか。

正しい方向へのポインタをいただければ幸いです。

スティーブケイン

編集:

  def get_integer_queryset(self, query, queryset):
    #stringify the first entry in query.keys (query is request.QUERY_PARAMS)
    query_key = str(query.keys()[0])
    #split the string into individual strings since the request object dict 
    #contains only a string of numbers and not an actual array (see below)
    #query = {'parameter':'1,2,3,4'} becomes {'parameter':['1','2','3','4']}
    query_values = query.get(query_key, None).split(",")
    #construct two dicts.  One handles integers and the other handles "null"
    #all the code below is required because Django does not seem to handle "null"
    #as a valid query to a field that is type "integer"
    #as a side note, I think this is poor and create annoying work...i would love
    #to be wrong here
    #the Q objects are required in order to compose a query of both integers and 
    #the string "null" 
    query_vals_no_null = {query_key+"__in": []} 
    optional_null_dict = {}
    for value in query_values:
      if value == "null" or value == "None":
        optional_null_dict[query_key+"__isnull"] = True
      else:
        query_vals_no_null[query_key+"__in"].append(value)
    return queryset.filter(  Q(**query_vals_no_null) | 
                             Q(**optional_null_dict)   )

これは、整数クエリを処理するカスタムビューから取得した主要なメソッドです。何が起こっているのかを明確にするためにコメントを挿入しました。これがおなじみの/ひどい/素晴らしい/やや穏やかに大丈夫に見えるかどうか教えてください。

スティーブ

4

1 に答える 1

2

django-filter (および REST フレームワークの対応する django-filter ベースのフィルター バックエンド) は、探しているものに最も近いすぐに使用できるアプリですが、ユース ケースを完全にはサポートしていないことがわかりました。特に次の理由で必要です。

  • クエリ文字列のnull/キーはサポートされていません。None
  • __inコンマ区切りを使用したスタイル ルックアップはサポートされていません。

(上記のいずれか/両方について間違っている可能性がありますが、ソース/ドキュメントを見回すとそう見えます)

つまり、オプションはおそらく次のとおりです。

  1. 必要に応じて正確に動作する独自のフィルタリングを記述します。
  2. 上記の 2 つの問題に対するサポートを に提供してdjango-filterください。
  3. 代替のフィルタリング アプリを探して使用し、必要なビュー全体で使いやすくするために、REST フレームワーク フィルター バックエンドでラップする可能性があります。

(3) のオプションのどれもが必要なことを完全に実行するとは思いませんが、tastypie と ピストン を簡単に掘り下げて、必要なことを実行するフィルタリング実装を提供するかどうかを確認し、何かをベースにすることをお勧めします。もしそうなら、それらの。

REST フレームワーク用の代替フィルター ソリューションのクローズド プル リクエストもあります。これは、__inスタイル フィルタリングをサポートしているようです。それが必要な場合は、チケットに対してコメントする価値があります。REST フレームワークで別のフィルター バックエンドを提供するために、チケットを再度開くことを検討できます。(理想的には、サード パーティのフィルター バックエンドとして。)

独自のフィルター ソリューションを引き続き使用し、より包括的なものになる場合は、REST フレームワーク グループで言及する価値があります。そうすれば、他の人がそれを使用できるようになります。より簡単に再利用可能なサードパーティのパッケージにまとめる価値がある場合。

この質問を更新して編集することにより、グループのいずれかで、あなたがどのようにうまくやっていくか教えてください.

于 2013-01-19T10:13:38.477 に答える