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.

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

update multiple records via ResultReference #315

Open
dcwatson opened this issue Jan 15, 2020 · 1 comment
Open

update multiple records via ResultReference #315

dcwatson opened this issue Jan 15, 2020 · 1 comment

Comments

@dcwatson
Copy link

Apologies if I missed it, but there doesn't seem to be a way to use a ResultReference to do a /set completely server-side. I think there are a number of good use-cases for being able to do this efficiently (mostly around updating based on a query), and I think it could be done with fairly minimal modifications to the spec. I'm imagining the ResultReference type gaining a new (optional) property -- call it properties or setProps or something -- that would cause the reference to resolve to a JSON object with the keys being taken from the pointer resolution, and values being whatever you pass. For example:

[["Email/query", {
    "accountId": "a1",
    "filter": {"from": "nobody"}
}, "eq"],
["Email/set", {
    "accountId": "a1",
    "#update": {
        "resultOf": "eq",
        "name": "Email/query",
        "path": "/ids",
        "properties": {
            "keywords/from-nobody": true
        }
    }
}, "es"]]

If the Email/query call returned {"ids": ["e1", "e2"]}, the Email/set call would resolve to:

["Email/set", {
    "accountId": "a1",
    "update": {
        "e1": {
            "keywords/from-nobody": true
        },
        "e2": {
            "keywords/from-nobody": true
        }
    }
}]

What do you think? Does this sound like something worth considering? My hunch is that it will require some discussion before it's worthwhile to create a PR, but I can take a stab at it if it would be helpful.

@neilj
Copy link
Member

neilj commented Jan 17, 2020

We didn't include something like this in the core spec (which is now published and final) because we were concerned about adding too much complexity. However, I think it's perfectly reasonable to have this as an extension if you would like to write it up and propose it to the JMAP working group.

The other thing I think this extension would probably want to define is some way of getting the server to omit some or all of the response (e.g. you don't need it to return you the Email/query response in your example, as it's just used for back references).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants