0

クエリ:

start: [ 2012101700 TO * ] OR end: [* TO 2012101700]

開始が今日の後であるか、終了が今日の前である結果が得られます。

このクエリは、開始または終了が欠落しているすべてのレコードを取得します。

 -(end: [ * TO *] OR start: [* TO *])

(奇妙なブラケットは、クエリパーサーの異常によるものです。参照:グループ化された Solr クエリが機能しない)

ただし、これらを組み合わせて、結果が定義された範囲内または完全に欠落しているすべてのレコードになるようにします。[* TO *] が台無しにするため、このクエリは機能しません。

(end: [ * TO 2012101700] OR start: [2012101700 TO *])
 OR -(end: [ * TO *] 
 OR start: [* TO *])

助言がありますか？

ありがとう

デイブ

4

2 に答える 2

3

Lucene は「OR NOT」スタイルのクエリをうまく処理しません。

その理由は、Lucene がデータを保存する方法にあります。反復するテーブルがなく、指定されたクエリに一致するものをすべて除外するだけです。私は実際に文書を見つけなければなりません。「OR NOT」クエリでは、一致するすべてのドキュメントを検索して除外できますが、一致しないドキュメントを検索する基準がないため、検索できません。

それについて考える別の方法は、データベースにクエリを実行するときに から始めることができSelect * from tablename、それが不足している情報です。レコードのテーブルに似た一連のドキュメントを識別する方法。

いくつかの実装により、このようなものが機能する可能性があります。また：

  • null の開始日と終了日に対して実際の値、プレースホルダーを保存し、代わりにその値を検索します。これはおそらく最良の選択肢です。

  • AND null start または null end のクエリは、次のように、関心のあるすべてのレコードに一致することがわかっている用語クエリ (上記の他の質問で得たクエリと同様) に一致します。

    (end: [ * TO 2012101700] OR start: [2012101700 TO *])
OR (term:GuaranteedHit AND -(end: [ * TO *] 
OR start: [* TO *]))

これを実現するには、フィールドを追加する必要がある場合があります。これにより、最初のオプションがより適切になる場合があります。ただし、フィールドを追加すると、テーブル名のように使用するフィールドを定義できるため、データベースのような構造をより直接的にエミュレートできます。

または、SOLR の uniquekey 機能を使用する場合は、すべてのドキュメントを検索するか、オブジェクトからクエリを手動で作成する場合は、 MatchAllDocsQueryid:[* TO *]を使用できます。

また、この 2 番目のオプションに優れたパフォーマンスは期待できません。

于 2012-10-17T17:37:19.720 に答える
1

クエリ：

-(start: [ * TO 2012101700] OR end: [2012101700 TO *])

実際には次と同等です：

(end: [ * TO 2012101700] OR start: [2012101700 TO *])
OR -(end: [ * TO *] 
OR start: [* TO *])

[* TO *]の用語は冗長です。他の用語には、範囲外のフィールドを持つドキュメントが含まれ、範囲がまったくないことも含まれます。

于 2012-10-18T09:58:33.460 に答える