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

Add mustExist flag to patch object #299

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

RubenVerborgh
Copy link
Member

This PR is an alternative to #298.

Delete semantics are not changed by default. Instead, a patch flag mustExist is added; if that flag is set to a falsy value, then a DELETE with a non-matching WHERE clause will silently not cause any effect.

Needed to address the incorrect SPARQL UPDATE semantics in nodeSolidServer/node-solid-server#1085.

@timbl
Copy link
Member

timbl commented Feb 8, 2019

Where is the flag passed? What is its default value?

@RubenVerborgh
Copy link
Member Author

Where is the flag passed?

On the patchObject, so by whatever parses that object.
The idea would be to set it to false for SPARQL UPDATE patches, and to an explicitly provided value in N3 patches.

What is its default value?

true, so existing behavior is preserved.

@timbl
Copy link
Member

timbl commented Feb 8, 2019

What will stop this flag breaking other implementations?

@timbl
Copy link
Member

timbl commented Feb 8, 2019

So N3 patches would work as semaphores and Sparql Update patches would not -- the mime type would be the key? And Solid-ui code would have to switch to n3 patches immediately ?
This means that any old solid-ui apps will fail -- can use user data -- with new servers.

@timbl
Copy link
Member

timbl commented Feb 8, 2019

Who would change Gold?

@RubenVerborgh
Copy link
Member Author

What will stop this flag breaking other implementations?

It is set to true by default, which is the old behavior.

So N3 patches would work as semaphores

N3 patches be able to specify a property solid:mustExist.
If set to true (default), they work as semaphores.
If set to false, they follow the SPARQL UPDATE behavior.

Sparql Update patches would not

Correct.

the mime type would be the key?

Correct (but behavior for N3 is overridable with solid:mustExist).

And Solid-ui code would have to switch to n3 patches immediately ?

They need to switch to N3 patches, as a correct implementation of SPARQL UPDATE does not have the semaphore behavior.

This means that any old solid-ui apps will fail -- can use user data -- with new servers.

Maybe, it depends how they do their updates.
If they use the rdflib.js update manager (i.e., not directly create SPARQL bodies themselves), they should be alright.

Who would change Gold?

I'm afraid I cannot help with that—but do we have many instances running still?

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

Successfully merging this pull request may close these issues.

2 participants