10 Commits

Author SHA1 Message Date
David Luecke
00cb0d9c30
feat(database): Add and to the query syntax (#3021) 2023-01-29 09:16:52 -08:00
David Luecke
66c4b5e720
fix(databases): Improve documentation for adapters and allow dynamic Knex adapter options (#3019) 2023-01-27 21:08:19 -08:00
Ashot Nazaryan
02c9e4e401
chore(docs): Fix link to workaround comment (#2949) 2023-01-02 14:05:26 -08:00
David Luecke
9ddc2e6b02
feat(adapter): Add patch data type to adapters and refactor AdapterBase usage (#2906) 2022-12-05 22:06:41 -08:00
Marshall Thompson
7fa2012897
fix(cli): mongodb connection string for node 17+ (#2875) 2022-11-18 13:48:25 -08:00
Marshall Thompson
f8bb525a5d
docs(mongodb): update examples to latest CLI code 2022-11-14 00:08:24 -07:00
David Luecke
c5c1fba571
feat(mongodb): Add ObjectId resolvers and MongoDB option in the guide (#2847) 2022-11-04 21:10:58 -07:00
Marshall Thompson
cb70e0778e
feat(mongodb) aggregation pipeline queries (#2840)
* feat(mongodb) aggregation pipeline queries

Makes queries using the MongoDB Aggregation Pipeline, by default, unless either of these conditions is met:

- `params.mongodb` is provided. This object is for the `collection.find` method, and won’t work for `collection.aggregate`.
- `params.query.$limit` is set to `0`. The aggregation pipeline will not accept 0 as a value for the `$limit` stage.

## Updates to `service.find`

The `find` method has been updated so that queries not meeting the two criteria, above, are created using the aggregation pipeline, which is an array of the document objects representing the stages of the request. Here’s an example query:

```ts
app.service(‘todos’).find({
  query: {
    $sort: { name: 1 },
    $skip: 1,
    $limit: 4
  }
})

// the internal aggregation request looks like this
const query = collection.aggregate([
  { $match: {} },
  { $sort: { name: 1 } },
  { $skip: 1 },
  { $limit: 4 },
  …params.pipeline || []
])
```

## New `pipeline` param

Notice that it’s now possible to pass `params.pipeline`.  This means you can set params.pipeline as an array of additional stages in the aggregation pipeline and they will be executed during the same request.  This means that it’s now possible to perform `$lookup` and `$unwind` stages alongside the normal Feathers queries.

## Feathers Query with `params.pipeline`

This example shows how to populate the `user` onto a query for `todos`, assuming that each `todo` contains a `userId` property.

```ts
const result = await app.service('todos').find({
  query: { $sort: { name: 1 } },
  pipeline: [
    {
      $lookup: {
        from: ‘users’,
        localField: 'userId',
        foreignField: '_id',
        as: ‘user’
      }
    },
    { $unwind: { path: '$user’ } }
  ],
  paginate: false
})
```

In the above example, the `query` is added to the pipeline, first (under the hood) then additional stages are added in the `pipeline` option:

- The `$lookup` stage creates an array called `user` which contains any matches in `todo.userId`, so if `userId` were an array of ids, any matches would be in the `users` array.  However, in this example, the `userId` is a single id, so…
- The `$unwind` stage turns the array into a single object.

All stages of the pipeline happen directly on the MongoDB server.

## Custom `.aggregate` requests

It’s still possible to make `.aggregate` requests without the Feathers syntax by directly accessing `service.model`:

```ts
const result = await app.service(‘todos’).model.aggregate([
   // …stages go here
]).toArray()
```

* refactor(mongodb): decouple find logic, getModel

Splits the `find` method into two utilities for converting params into MongoDB requests:

- `asFindQuery`
- `asAggregateQuery`

Each of the above methods returns the raw MongoDB request object, without having called `.toArray`, so it’s likely also possible to directly use MongoDB cursors on the returned object, though I’ve not added a test for such a use case.

This PR also optimizes the `find` method to parallelize the `count` query (for pagination) and the `results` query.  This makes it so we don’t have to wait for the count before we start querying the results.

One more thing: this PR also combines non-DRY code that was found in every method into a single `getModel` method.

* feat(mongodb) control stages with $feathers stage

A custom `$feathers` stage has been added to our wrapper for the MongoDB aggregation pipeline.  It allows you to specify where in the pipeline the Feathers-related stages get injected.  This means you can now specify for some pipeline operations to run BEFORE the ones related to the Feathers query.

The `$feathers` stage is an object optionally containing a `handleStages` function.  The `handleStages` function receives the Feathers stages and allows them to be modified.  It’s a feature that will only be used in complex, modular/layered queries, since it would usually be simpler to just modify the incoming query before passing it to `service.find`.

* refactor(mongodb) rename utils and combine methods

- rename `asFindQuery` to `findRaw`
- rename `asAggregateQuery` to `aggregateRaw`
- combine the `makePipeline` method into the `aggregateRaw` method,

* docs(mongodb) document aggregation queries

* feat(mongodb) remove handleStages from aggregation
2022-11-04 15:58:35 -06:00
David Luecke
eeb62e13ef
chore(docs): Add current v5 API docs (#2805) 2022-10-17 12:49:03 -07:00
Marshall Thompson
ae85fa216f
feat(docs): New website and documentation pages (#2802)
* feat(docs) new docs site started

* Minor page edits

* feat(footer) fix spacing

* empty guides template

Co-authored-by: daffl <daff@neyeon.com>
2022-10-17 13:05:01 -06:00