問題タブ [n1ql]

ここで問題に直面しています。Nickel を使用して Couchbase にクエリを実行しています。クエリは次のとおりです。

しかし、ここで取得している値は更新されていませんが、しばらくしてから同じリクエストを行うと、目的の出力が得られます。

INDEXを作成するために使用したクエリは

はどこtsですかTimeStamp。

常に更新されたデータを取得できる方法があれば教えてください。

前もって感謝します。どんな種類の助けも大歓迎です。

4.0での作業。
「./cbq-engine -datastore= http://localhost:8091」を実行しました。
ログの最初のメッセージは次
のとおりです。
実際、CREATE PRIMARY INDEX を実行しようとすると、
「インデクサーが実装されていません GSI が有効になっていない可能性があります」というエラーが表示されます。

こんな問い合わせがあったら

次のような結果になります。

しかし、次のようなものが必要な場合はどうなりますか:

私は次の結果になりたいと思います：

次のような簡単なクエリがあります。

それは私にjsonを与えます：

しかし、必要なのは文字列のフラットな配列です:

どうすればそれを達成できますか？

Tornado アプリケーションを作成していて、非同期 N1QL クエリを作成する必要があります。txcouchbase (ツイスト カウチベース ライブラリ) をトルネード ツイスト ブリッジと共に使用する map-reduce ビューでは問題なく動作しましたが、N1QL クエリに対して同じことを行うことはできません。

次のクエリresオブジェクトを実行すると、反復可能ではなく、次のようになります。

フィールドにはクエリの結果が含まれているようですが、これが非同期N1QL_BatchedRowMixin__rowsクエリを作成する正しい安定した方法であるかどうかはわかりません。他のオプションはありますか？

私はこのような文書構造を持っています

map & reduce 関数を使用してそれを行う方法を見つけました。

http://guide.couchdb.org/draft/cookbook.html

ただし、n1ql を使用して同じクエリを実行したい場合、どうすればよいでしょうか?

前もって感謝します。

さまざまな種類のドキュメントで機能する一般的なクエリを作成することはできますか? たとえば、「ケース」と「工場」があり、それらには異なるフィールドのセットがあります。例えば：

エンティティのタイプ (ケースまたはファクトリ) と追加のパラメーターを渡し、それらに基づいて結果をフィルター処理する一般的なクエリを作成することは可能ですか? もちろん、JavaScript ビューを使用することもできますが、複数のフィールドでフィルター処理することはできません。ベネズエラにある、従業員数が 20 から 55 のすべての工場を取得したいとします。

私はこれで始めましたが、行き詰まりました：

複数の述語を渡し、クエリでそれらを認識させるにはどうすればよいですか?

もちろん、次のようにフィールドを一覧表示できます。

しかしその後

• エンティティごとに個別のクエリを作成する必要があります
• それでも私の問題は解決しません - 述語を無視する方法がわかりません.次回 $workers_min と $workers_max が渡されなかった場合、述語 (列) ごとにクエリを作成する必要がありますか?
• セキュリティ上の理由から、自由形式のクエリを生成して Couchbase サーバーに渡すことはできません。すべてのクエリは既にデータベースに保存されており、API はドキュメントからクエリを取得して実行するだけです。
• WHERE $location IS MISSING OR entity.location == $location未定義の引数（たとえば、またはそのようなもの）に対して「短絡」するクエリを作成することは可能だと思います

任意のパラメータに基づいてデータセットを効果的にフィルタリングおよび順序付けできるクエリを作成することはまったく可能ですか? それとも仕方がない？

.NET SDK を使用しています。

null を文字列として渡すことは機能せず、実際の null 値を渡すと次の例外がスローされます。

オプションの検索パラメーターを使用してクエリを作成しようとしています。ここで、ユーザーが検索することを決定しなかったパラメーターに null を渡します。

User、Message、MessageFeatures などのエンティティを持つアプリケーションがあります。各 User は多数のメッセージを持つことができ、各メッセージには MessageFeatures エンティティがあります。現在、リレーショナル モデルは次のように表現されます。

最も重要なクエリは次のとおりです。

• ユーザーのすべてのメッセージを取得する
• ユーザーのすべてのメッセージ機能を取得する
• uuid でメッセージを取得する
• uuidによるメッセージ取得・更新機能
• メッセージ uuid によるメッセージ機能の取得

重要度の低い (遅くなる可能性がある) クエリは次のようになります。

• user_id = someuuid および featureX = value のメッセージ機能を取得します
• featureX = value のすべて/カウントのユーザー uuid を取得します
• update message features set featureX = newValue where featureX = oldValue

カウチベースの評価中に、適切なデータ モデルに到達できません。ユーザー向けのすべてのメッセージとメッセージ機能を 1 つのドキュメントにまとめることは良い考えではないと思います。サイズは増え続け、現在のデータに基づくと 2 年間のデータで 4 ～ 5 MB の範囲に簡単に収まるからです。また、一貫性を維持するために、原子性はドキュメントごとにあるため、一度に 1 つのメッセージ機能のみを更新できます。

それらを単一のドキュメントに配置しないと、それらはクラスターの周りに散らばり、ユーザーのすべてのメッセージ/メッセージ機能を取得するようなクエリは、散らばって集まります。

グローバル セカンダリ インデックスと N1QL を確認しましたが、メッセージの user_uuid フィールドにインデックスを付けても、そのユーザーの message_uuids を取得するのに役立つだけで、すべてのメッセージをロードすると分散と収集が発生します...

すべてのメッセージ、user_uuid のメッセージ機能を、redis のハッシュタグのような同じドキュメントに埋め込むことなく、同じ物理ノードにマップすることを強制する方法はありますか?