MongoDB Queries

These queries are converted to MongoDB filters and aggregations by MongoQueryProducer.

These queries support all available query types and convert them to Bson maps or lists for execution. Pipeline queries are treated as aggregate pipelines and bundled queries are treated as facets.

MongoDB specific features for special use cases are as follows:

Query Parameters

Parameter	Definition
matchAfterJoin	Whether the where condition should execute after joins or before (i.e. on main collection), defaults to false
pipe	Whether the query should be generated as an aggregate pipeline instead of a find query

When there is a join condition on a query, it is automatically produced as an aggregate pipeline. The "pipe" parameter is only recommended when some aggregate operators will be used on an otherwise basic query.

Join Parameters

MongoDB query manager translates joins into $lookup statements, with 2 alternative methods:

$lookup (aggregation)mongodb

MongoDB $lookup

Simple Lookup

The simple lookup method uses only a simple "EQ" type condition, where localField of "from" collection maps to "Expression" and foreignField of "join" collection maps to "Value".

Example Simple Lookup

Complex Lookup

The complex method uses pipeline feature of MongoDB lookups, where 2 alternative approaches can be used:

Using Parameters

With this approach, lookup pipeline can be manually configured using the following condition parameters:

Parameter	Definition
let	Map of variables to expressions as "let" statement in "$lookup" stage (e.g. {"id":"$_id"})
pipeline	List of steps for "pipeline" to run on joined collection in "$lookup" stage (as array node or string)

Using Join Condition

When a complex condition is used for joining with a collection in query designer (e.g. using AND, OR or anything other than EQ operator), MongoDB query manager automatically translates the join into a pipeline based lookup. This option allows using regular conditions (including ability to use parameters such as required variables), which will be automatically translated into $match statements.

When using this approach, it is possible to add the following parameters:

Parameter	Definition
let	Map of variables to expressions as "let" statement in "$lookup" stage (e.g. {"id":"$_id"})
extra	List of steps for adding to "pipeline" after the produced $match statement (as array node or string)

Common Mongo Parameters

Following parameters are applicable in various building blocks of a MongoDB query:

Parameter	Definition
mongo	Json object to be used as the field expression
mongo.inject	Whether "mongo" parameter should be injected with variables
mongoJson	Json string to be used as the field expression
	Whether "mongoJson" parameter should be parsed into a json object before injection
mongoJson.inject	Whether "mongoJson" parameter should be injected with variables

Field Parameters

For both custom simple and aggregation fields, "Common Mongo Parameters" are applicable.

Operatorsmongodb

MongoDB Operators

In defining field expressions for simple and aggregation fields, it is possible to use any MongoDB expression.

However, if the first character is a "$", it should be omitted (e.g. instead of $id, expression should be id, instead of $$ROOT, expression should be $ROOT). Query manager automatically adds a "$" character, if the first character is not "{". This convention is used to allow more standardized expressions between different systems.

Custom Condition Operators

For simple conditions, MongoDB supports following custom operators:

• value: Uses "filter" parameter (e.g. $eq) as the check between rhs and lhs values of the condition.

• values: Same as value operator, accepting multiple values as the rhs.

• bson: Uses "Common Mongo Parameters" to build a Bson statement as the condition.

It is also possible to use any mongodb operator (e.g. $exists) as a custom operator, which uses a single rhs value (e.g. "true") along with the lhs (e.g. data.records).

MongoDB Java driver automatically hides "$and" operator in certain scenarios in older versions of the library (i.e. when multiple entries with same key doesn't exist). This can result in issues in rare complex condition scenarios (e.g. $not allowed as a root level operator). In such case, conditions inside the AND operator can be written as custom expressions instead.

Custom Pipeline Steps

For pipeline steps, MongoDB supports following types:

• custom: Pipeline step is produced directly from "Common Mongo Parameters" of the step content.

• condition: Step content represents "where" condition of a query.

• join: Step content represents "join" condition of a query.

• select: Step content represents "fields" of a simple query.

• aggregate: Step content represents "fields" of an aggregation query.

• orderBy: Step content represents "orderBy" of a query.

• skip: Uses "value" text field of the step content to skip number of records.

• limit: Uses "value" text field of the step content to limit number of records.

Examples

527B

customer_segments.json

Select Customer Segment by Id (Can be Imported on Query Screen)

7KB

product_detail_query.json

Product Details with Joins and Expressions (Can be Imported on Query Screen)

5KB

product_list_bundle.json

Product List with Bundled Total Count (Can be Imported on Query Screen)

6KB

product_variant_feed_es.json

Pipeline with Unwind (Can be Imported on Query Screen)