User story #7877: [API] Make group query editable by each query piece - Rudder - Issue Tracker

Actions

Copy link

User story #7877

open

[API] Make group query editable by each query piece

Added by Janos Mattyasovszky almost 9 years ago. Updated over 2 years ago.

Status:

New

Priority:

N/A

Assignee:

Category:

API

Target version:

Ideas (not version specific)

Pull Request:

UX impact:

Suggestion strength:

User visibility:

Effort required:

Name check:

Fix check:

Regression:

Description

Currently when editing a Group's query, you'll have to upload the whole select-statement in json.

This is prone to race condition, becuase if the size of the query is big (let's say you have 4000 nodes in a query, selected by UUID), fetch the group, edit it according to your needs, and re-upload it, chances are greater then zero (depends on usecase), that it has been edited by someone other, not to say about the necessary roundtrip-time it takes unnecessarily.

Proposing a function to add/remove items from the "where"-array:

Example:

{
  "select": "node",
  "composition": "Or",
  "where": [
    {
      "objectType": "node",
      "attribute": "nodeId",
      "comparator": "eq",
      "value": "5ea1cb80-f4d3-11e4-be7b-228f081228de" 
    },
    {
      "objectType": "node",
      "attribute": "nodeId",
      "comparator": "eq",
      "value": "0cfc3466-3e8c-11e5-bc06-5453cf67da3d" 
    },

Add a new where-clause:

curl -H "X-API-Token: yourToken" -X POST 'http://rudder.example.com/rudder/api/latest/groups/GroupID/QueryStatement' -d "WhereClause='
    {
      "objectType": "node",
      "attribute": "nodeId",
      "comparator": "eq",
      "value": "afa11fa0-a2b1-4f00-b33f-44b91aaf443d" 
    }'"

Delete the first where-clause:

curl -H "X-API-Token: yourToken" -X DELETE 'http://rudder.example.com/rudder/api/latest/groups/GroupID/QueryStatement' -d "WhereClause='
    {
      "objectType": "node",
      "attribute": "nodeId",
      "comparator": "eq",
      "value": "5ea1cb80-f4d3-11e4-be7b-228f081228de" 
    }'"

Change it to "and" logic:

curl -H "X-API-Token: yourToken" -X POST 'http://rudder.example.com/rudder/api/latest/groups/QueryStatement' -d "composition=And"

Replace the second by a different clause:

curl -H "X-API-Token: yourToken" -X POST 'http://rudder.example.com/rudder/api/latest/groups/QueryStatement' -d "WhereClause=' { "objectType": "node", "attribute": "nodeId", "comparator": "eq", "value": "0cfc3466-3e8c-11e5-bc06-5453cf67da3d" }'" -d "NewWhereClause=' { "objectType": "node", "attribute": "nodeId", "comparator": "neq", "value": "abbaedda-acdc-face-b00c-123456789012" }'"

Actions

Copy link

Updated by Janos Mattyasovszky almost 9 years ago

PS: The "remove parts" feature is already present in: "Nodes / 5. Set Node properties / Remove key (bis)"

Actions

Copy link

Updated by François ARMAND almost 9 years ago

Thanks for the use case.

If U understand correctly, the problem is independant from the size of the request, it's just exacerbated by them. It could arise if you add:

Initial stat: select nodes where uuid = node1

And concurrently:
User 1: select nodes where uuid = node1 or node2
User 2: select nodes where uuid = node1 or node3

There, the final state may be either the one of user1 or user2 depending of the timing of the requests.

But I'm not sure I completelly understand what you want. As far as I understand, to have a complete controle, you need 3 operation on where clause:
- 1/ a "set" one, where you are defining the exact final state (only current possibility)
- 2/ a "remove on criterion", where you specify a criterion to remove (and it the new clause is the old one with that criterion filtered out (and so the same if criterion is not present)
- 3/ a "add one criterion", where you specify a criterion to add (and the new clause is the old one + that criterion, or the same if the criterion was already in the where clause)

And you can construct replace from 2 + 3 in the same request (making it even more resistant to race condition, but you are loosing the possibility to fail if the criterion is not in the request).
And if 2 and 3 are multivalued, you can easely mass-change a where clause in on go.

Did I understand what you wanted to achieve ?

Actions

Copy link

Updated by Janos Mattyasovszky almost 9 years ago

Yes, you understand it correctly.

If you have concurrent access to the API from clients with different roundtrip-times for the get-group-json/make local edits/set-group-json trio, it might be possible that they will overwrite each other's settings, because the get/set is not an atomic operation, but an "add-exactly-this" and "remove-exactly-this" would be... If it would be already added, no action is needed, or if it's not present, also no action is needed.

Currently the only actor capable to make sure edits on a (basically) json string inside the ldap is atomic is the processing unit inside the API endpoint, no client can make locks or double-check before sending his updated full-blown json back.

Actions

Copy link