Comments (7)
Because validators are run on the horizon server, and not on the database, if two clients attempt to write to the same row at the same time, one will have a conflict and fail. This applies to almost all combinations of writes between the two clients - the only case I can think of off the top of my head that wouldn't error is if both clients are attempting to remove the document.
There is no reason this needs to happen when the requests match rules without validators, as then we could resolve the conflict atomically in the database. This would be solved by rethinkdb/horizon#380, which is not a huge task, but I wanted to keep the testing surface area small right before release.
As for individual writes and their error cases, they are as follows:
- All writes may fail if they do not pass the template and optional validator of at least one rule available to the user account of the current session
insert
- Fails if the document with that ID already exists (if no ID is specified,
insert
should never fail)
- Fails if the document with that ID already exists (if no ID is specified,
remove
- Fails if the document version has changed between when we fetch it for the validator and when we perform the remove
replace
- Fails if the document is not present
- Fails if the document version has changed between when we fetch it for the validator and when we perform the replace
- Fails if the document was removed between when we fetch it for the validator and when we perform the replace
update
- Fails if the document is not present
- Fails if the document version has changed between when we fetch it for the validator and when we perform the update
- Fails if the document was removed between when we fetch it for the validator and when we perform the update
store
(insert with replace)- Fails if the document version has changed between when we fetch it for the validator and when we perform the store
- Fails if the document was removed between when we fetch it for the validator and when we perform the store
- Fails if a document with the same ID was created between when we fetch it for the validator and when we perform the store (if no ID is specified,
store
should never fail)
upsert
(insert with update)- Fails if the document version has changed between when we fetch it for the validator and when we perform the upsert
- Fails if the document was removed between when we fetch it for the validator and when we perform the upsert
- Fails if a document with the same ID was created between when we fetch it for the validator and when we perform the upsert (if no ID is specified,
upsert
should never fail)
from horizon-docs.
Thanks @Tryneus .
I thought we were pushing the version through to the client to catch cases like
- client A fetches a document
- client A modifies it locally, while
- client B changes the document through a separate write
- client A writes back the modified document through
replace
I thought the last step would fail because the versions don't match, but I guess we didn't end up actually implementing this?
from horizon-docs.
@danielmewes, you're right, that is still possible to do, actually - although you have to do it explicitly in the client using the new version values you receive from your write responses.
If a client explicitly specifies the version that they want to modify, we use that version when performing checks rather than the version from the initial fetch for the validator.
from horizon-docs.
Oh cool, but how do I specify the version to a write? Do I just place the version field that I get from a write response into the document for the next write?
Is there a way for getting the current version of a document through a read, without writing to it first?
from horizon-docs.
There isn't a current way to get the version of the document through a read as far as I know. The server does send this information to the client, but the version field is filtered out by the client at the moment to avoid users accidentally performing stricter writes that may cause problems at high loads (two clients performing strict writes repeatedly will always favor the client with the lowest latency). Perhaps there should be an option in the client to stop this filtering.
from horizon-docs.
And yes, if you want to perform a write that will only apply to a certain version, you just include the $hz_v$
version field in the document to be written.
from horizon-docs.
jlu
on hackernews, just chiming in to say thanks for tracking this issue, good job!
from horizon-docs.
Related Issues (20)
- Upgrade docker-compose files to v2 of the docker-compose file spec HOT 8
- Document integration with specific frameworks (React etc.) HOT 2
- Users doc misleading
- cookbook entry: subscribing to changing data
- Horizon 2.0 docs checklist HOT 27
- Document `Collection.update`, `Collection.insert` and correct existing write commands
- Clarify client constructor host option
- .filter() listed twice in Observable's methods. HOT 1
- We need a guide on "Deploying Horizon"
- New page about Horizon client packaging HOT 2
- Section headers should be clickable to put the fragment in the URL path
- Document admin user requirement
- Permissions only mentions `.find` once but it isn't clear if using `.findAll` covers `.find`? HOT 2
- Auth documentation needs to show boilerplate on how to handle connections by unauth'd and auth'd users
- Embedding docs incorrectly uses `_reql_conn` as a property of the server module HOT 2
- Document how to use JWT generated using CLI
- horizon js can not access rethinkdb in port 28025 without --dev flag . Error : action not permitted .
- Docs at http://horizon.io/docs/auth/ don't say what callback URL to use HOT 8
- Include section in FAQ on why full ReQL queries aren't supported in Horizon
- Document .aggregate and .model HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from horizon-docs.