Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feature(aggregate): added support for 2 additional use-cases while ma… #316

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

feature(aggregate): added support for 2 additional use-cases while ma… #316

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "mongo-cursor-pagination",
"version": "7.6.1",
"version": "7.7.0",
"description": "Make it easy to return cursor-paginated results from a Mongo collection",
"main": "index.js",
"files": [
Expand Down
37 changes: 18 additions & 19 deletions src/aggregate.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,8 @@
const _ = require('underscore');
const sanitizeParams = require('./utils/sanitizeParams');
const { prepareResponse, generateSort, generateCursorQuery } = require('./utils/query');

const config = require('./config');
const { prepareResponse, generateSort, generateCursorQuery } = require('./utils/query');
const sanitizeParams = require('./utils/sanitizeParams');

/**
* Performs an aggregate() query on a passed-in Mongo collection, using criteria you specify.
Expand Down Expand Up @@ -34,29 +35,28 @@ const config = require('./config');
* -after {String} The _id to start querying the page.
* -before {String} The _id to start querying previous page.
* -options {Object} Aggregation options
* @param {(() => number) | undefined | null} getPipelineIndexFn Functor that determines where to insert the pagination-specific operations in the pipeline
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a unit test demonstrating a "real world" scenario for this parameter. My understanding from reading the code is that it's useful only if you have multiple $match stages in your aggregation. This parameter will allow you to pick where in the pipeline to insert the 3 stages required for pagination.

Please add unit tests that cover the newly added lines. We want to maintain near-100% unit test coverage in this module.

* This parameter controls the placement of the pagination-specific operations in the pipeline to allow more advanced use cases
* - undefined => preserves legacy behavior (backwards-compatible)
* - null => allows a more "common" behavior that allows data transformation prior to pagination (eg. includes reshaping _id value to be used in default pagination)
* - custom function => allows for a user-defined impl (special/advanced cases such as post-processing of results server-side)
*/
module.exports = async function aggregate(collection, params) {
module.exports = async function aggregate(collection, params, getPipelineIndexFn) {
params = _.defaults(await sanitizeParams(collection, params), { aggregation: [] });
const cursorQuery = generateCursorQuery(params);
const $sort = generateSort(params);

let index = _.findIndex(params.aggregation, (step) => !_.isEmpty(step.$match));

if (index < 0) {
params.aggregation.unshift({ $match: cursorQuery });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding of the existing behavior is that if a $match step isn't included params.aggregation, this code will add $match as the first step. Is this behavior preserved in the refactor?

index = 0;
} else {
const matchStep = params.aggregation[index];

params.aggregation[index] = {
$match: {
$and: [cursorQuery, matchStep.$match],
},
};
if (getPipelineIndexFn === undefined) {
getPipelineIndexFn = () => _.findIndex(params.aggregation, (step) => !_.isEmpty(step.$match));
} else if (getPipelineIndexFn === null) {
getPipelineIndexFn = () => params.aggregation.length - 1;
}
const index = getPipelineIndexFn();

params.aggregation.splice(index + 1, 0, { $sort });
params.aggregation.splice(index + 2, 0, { $limit: params.limit + 1 });
// assumes consecutive matches can/should be optimized by the server engine rather than client side
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you test this on a large collection to be sure? I don't recall why we optimized this in client-side code (by merging the $match queries together), but we might have tested it and realized it was necessary.

params.aggregation.splice(index + 1, 0, { $match: cursorQuery });
params.aggregation.splice(index + 2, 0, { $sort });
params.aggregation.splice(index + 3, 0, { $limit: params.limit + 1 });

// Aggregation options:
// https://mongodb.github.io/node-mongodb-native/3.6/api/Collection.html#aggregate
Expand All @@ -76,7 +76,6 @@ module.exports = async function aggregate(collection, params) {
// Support both the native 'mongodb' driver and 'mongoist'. See:
// https://www.npmjs.com/package/mongoist#cursor-operations
const aggregateMethod = collection.aggregateAsCursor ? 'aggregateAsCursor' : 'aggregate';

const results = await collection[aggregateMethod](params.aggregation, options).toArray();

return prepareResponse(results, params);
Expand Down