SoftInstigate/restheart

RESTHeart, Instant RESTFul API for MongoDB

Andrea Di Cesare

@ujibang

Also you might define the aggregation as follows

{
  ...,
  "_$match": { "personId": {"_$id": { "_$var": "personId" }}},
 ...
}

and pass the avar as avars={‘personId’: ['xyz123','abc456’] }

Damien

@dev-indb

Hi Andrea. Thanks for your help

3.2.0 version is ok ?

Andrea Di Cesare

@ujibang

well 3.2 is quite old (latest is 4.1.10, latest in 3.x is 3.10.1) and we are going to publish 5.0 in few weeks

Damien

@dev-indb

I know .. it is the version in production

Andrea Di Cesare

@ujibang

I don’t remember when aggregation-check-operators was added to allow using operators in aggregation variables

Damien

@dev-indb

it doesn't seem to be working in 3.2. IO will try with later version

Andrea Di Cesare

@ujibang

it was introduced in 3.3.0

Damien

@dev-indb

    "http status code": 500,
    "http status description": "Internal Server Error",
    "message": "error executing aggreation pipeline",
    "_embedded": {
        "rh:exception": [
            {
                "exception": "org.restheart.handlers.metadata.InvalidMetadataException",
                "exception message": "wrong variable name { '$in' : 'personId' }"
            }
        ]
    },
    "_links": {
        "self": {
            "href": "/recrutby/candidates/_aggrs/personids_count"
        }
    }
}

3.3.0 .. cool ... migration could be easier !

Andrea Di Cesare

@ujibang

exactly. you can try the second option I sueggested if you are stick to 3.2

I think you can safely update to 3.10.1

Damien

@dev-indb

What is the first option you suggested ?

Andrea Di Cesare

@ujibang

you can define the aggregation as follows

Also you might define the aggregation as follows
{
  ...,
  "_$match": { "personId": {"_$in": { "_$var": "personId" }}},
 ...
}

and pass the avar as avars={'personId': ['xyz123','abc456’] }

Damien

@dev-indb

"$id" or "$in" ?

_$in .. the operator no ?

Andrea Di Cesare

@ujibang

_$in yes, there was a typo

Damien

@dev-indb

ok
Thank you for everything. I'll get back to you

Andrea Di Cesare

@ujibang

you are welcome, let me know if it works! bye

Damien

@dev-indb

RESTHeart rocks !

1 : set aggregation-check-operators to false

# Check if aggregation variables use operators. allowing operators in aggregation variables
# is risky. requester can inject operators modifying the query
aggregation-check-operators: false

2 : don't add the operator in the "aggrs" metadata

  "aggrs": [
    {
      "stages": [
        {
          "_$match": { "personId": { "_$var": "personId" }}
        },
        {
          "_$group": { 
            "_id": "$personId", 
            "count": { "_$sum": 1 }
          }
        }
      ],
      "type": "pipeline",
      "uri": "personids_count"
    }
  ]
}

3 : add the operator in the query

http://localhost:9998/recrutby/candidates/_aggrs/personids_count?avars={'personId':{'_$in':['xyz123','abc456']}}
{
    "_size": 2,
    "_total_pages": 1,
    "_returned": 2,
    "_embedded": {
        "rh:result": [
            {
                "_id": "xyz123",
                "count": 46
            },
            {
                "_id": "abc456",
                "count": 48
            }
        ]
    }
}

Many thanks !

RESTHeart version 3.10.1

Damien

@dev-indb

Typo : remove _ before $in

http://localhost:9998/recrutby/candidates/_aggrs/personids_count?avars={'personId':{'$in':['xyz123','abc456']}}

Andrea Di Cesare

@ujibang

yes! _ prefix is only required to store the aggregation, not in the query parameter

pejobo

@pejobo

Hi, I've got a question about the documentation for POST:
POST - Upserts a resource under the resource identified by the request URL
from https://restheart.org/docs/write-docs/

Is this a type or does POST really performs an upsert?

Andrea Di Cesare

@ujibang

yes POST upsert documents

if the body contains the _id property and if that _id matches an existing document, it updates it. otherwise it creates a new document.

pejobo

@pejobo

okay, thanks for your answer - I was hoping it is a typo.. ;)

Andrea Di Cesare

@ujibang

you can easily avoid it to create or update documents

pejobo

@pejobo

How would I do it?

Andrea Di Cesare

@ujibang

if you want the POST to only create documents, just add ?checkEtag query parameter

it forces the update to specify an ETag. checkEtag

see more https://restheart.org/docs/etag

so in case you pass an _id and the doc exists, the update fails because the If-Match header does not match the _etag

pejobo

@pejobo

Can I enforce the "checkEtag" for POST for a collection somehow?

Andrea Di Cesare

@ujibang

if you need it only for one specific collection you can create a tranformer that adds the qparameter to every request on that collection

if you want it to all collections, you can simply change the default etag policy configuration

## ETag policy

# the following configuration defines the default etag check policy
# the policy applies for dbs, collections (also applies to file buckets) and documents
# valid values are REQUIRED, REQUIRED_FOR_DELETE, OPTIONAL

etag-check-policy:
    db: REQUIRED_FOR_DELETE
    coll: REQUIRED_FOR_DELETE
    doc: OPTIONAL

this is the configuration. You see it is OPTIONAL for documents

pejobo

@pejobo

Is there something like REQUIRED_FOR_POST?

Andrea Di Cesare

@ujibang

REQUIRED

also applies for PUT and PATCH

pejobo

@pejobo

Ah, I also found it - thank you.

Andrea Di Cesare

@ujibang

ps of course if you make sure that the request does not include the _id field it will always be an insert. I often use this approach (removing the _id in POST requests) and only use PATCH for updates.

pejobo

@pejobo

we need this for an api key collection and the generated oid isn't secure enough

Andrea Di Cesare

@ujibang

I see. What about creating the secure _id server side via a transformer?

pejobo

@pejobo

I was hoping for a quick change here, because we want to change the authentification process in the not-so far future and I do not want to invest too much time in the old api key way..

But yeah, a transformer would be a possible way

Maurizio Turatti

@mkjsix

Hi all, we are releasing RESTHeart v5, at present it's RC2 (release candidate 2). Work si not finished yet, but please have a look at the update introductory documentation on master branch and let us know: https://github.com/SoftInstigate/restheart/blob/master/README.md

Where communities thrive

People

Repo info

Activity