-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
🚀 Feature: Optimistic Concurrency #5348
Labels
enhancement
New feature or request
Comments
Thank you for opening this. We will keep this issue open for now for developers to see and upvote it if they want this! |
Simply by adding an optional param "Query[]" (a where clause) in Update methods, will make optimistic concurrency available for developers who wants to apply it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
🔖 Feature description
Optimistic concurrency allows to manage the update of a "document or record" when multiple users try to update it at the same time. For instance, user A open the form of document X and start to edit it; after a few seconds/minutes user B open the same form of document X and "edit and save" faster than user A, so, when user A click "save" button a popup or error appears saying that the document has changed (with a button to query the document again).
🎤 Pitch
Many backend frameworks implement this out-of-the-box, like .NET abp framework:
https://docs.abp.io/en/abp/latest/Concurrency-Check
And it is a necessary feature for enterprise domains. An example of a use case is manufacturing process:
lets say in the BOM (bill of materials) of a product we have 30 parts, and there are a lot of supervisors that request parts via an APP (that uses appwrite) to start the production in each line; if 2 or more supervisors open the same order (with 100 ordered products) and they request the entire order, without optimistic concurrency 6000 part will be get from inventory instead of 3000, and no body knows that until the parts arrive to the lines or the finished product inventory. Optimistic concurrency avoid the need of comunication between supervisors, or that certains supervisor only can touch certain orders (bad practice in some companies), etc, etc.
Optimistic concurrency helps to simplify those kind of use cases, other example is when someone update the price of a product in an order or buget document.
👀 Have you spent some time to check if this issue has been raised before?
🏢 Have you read the Code of Conduct?
The text was updated successfully, but these errors were encountered: