Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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
    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