11
1
Introduction:
Ever used Dropbox with some other people and you both modified the same file? Ever had a multi-user application with a relational database, and two people were modifying (or worse, one was deleting and the other modifying) the same object? Well, let's simulate that with this challenge (sort-of).
For the sake of this challenge, we only have two users and either one or two relevant files. Both users have in general privileges to CRUD (Create, Read, Update, and Delete) all files.
Challenge:
Input:
We'll have a few inputs (input format is flexible, and any reasonable format is allowed):
1) Locking mode (on/off): Kinda the difference between optimistic and pessimistic concurrency locking.
Both users are allowed to CRUD (Create, Read, Update, and Delete) everything, but sometimes errors or problems can occur. Depending on the locking mode a problem when turned off, could be an error when turned on. This is explained below in the Output section.
2 & 3) Two user-actions. These actions always consist of two things: What the user does (Create, Read, Update, or Delete) and for which file.
Output:
We'll have three possible outputs:
- Valid: Both actions by both users can be done simultaneously without any issues occurring.
- Error: Both actions by both users cannot be done simultaneously and causes an error for one of the users (which user is irrelevant for this challenge). This can occur when:
- one user Reads or Updates a file, which the other user Deletes;
- both users Update the same file with locking mode turned on;
- a user Creates a file, which the other user Reads/Updates/Deletes (this means the file already exists, so it cannot be Created);
- both users Create the same file.
- Problem: Both actions by both users can be done simultaneously, but can cause unexpected problems. This can occur when:
- both users Update a file when locking mode is turned off;
- one user Updates a file, which the other user Reads;
- both users Delete the same file (practically this will causes an error for the second user, but since it will still be deleted like the user wants, it will be a problem instead of an error for the sake of this challenge)
Challenge Rules:
- All input and output is flexible, and everyone should state which one they've used in their answer!
Example inputs:0
/1
for locking mode &31
(third action: Update; file: 1) &21
(second action: Read; file: 1);true
/false
for locking mode &['C','A']
(action: Create; file: A) &['D','B']
(action: Delete; file: B); etc.
Example outputs:null
/true
/false
(null = valid; true = error; false = problem);-1
/0
/1
(-1 = error; 0 = problem; 1 = valid); etc. The three possible outputs have to be unique and distinct for the three output-type, though. - What the files are called is irrelevant, which can also be seen with the input-examples above. So feel free to use any type of file name in your answers consisting of a single (ASCII) letter or digit. They do have to be consistent across all your test cases however, so you can't use
A
/B
in one test case and1
/2
in another. - The four actions for CRUD have to be unique and consistent values as well. So you cannot use
'D'
/'C'
in one test case, and then4
/1
in another test case. - You can assume that the file chosen by a user always exists when they want to Read, Update, or Delete it.
General rules:
- This is code-golf, so shortest answer in bytes wins.
Don't let code-golf languages discourage you from posting answers with non-codegolfing languages. Try to come up with an as short as possible answer for 'any' programming language. - Standard rules apply for your answer with default I/O rules, so you are allowed to use STDIN/STDOUT, functions/method with the proper parameters and return-type, full programs. Your call.
- Default Loopholes are forbidden.
- If possible, please add a link with a test for your code (i.e. TIO).
- Also, adding an explanation for your answer is highly recommended.
All possible test cases (where the actions can be in either input-order†):
†: You should support all (up to four) variations of the test cases below. So if a test case states action1: Create file A; action2: Update file B
, that test case should also hold the same results for action1: Create file B; action2: Update file A
; action1: Update file B; action2: Create file A
; and action1: Update file A; action2: Create file B
.
Valid use-cases:
locking mode: either; action1: Create file A; action2: Create file B
locking mode: either; action1: Create file A; action2: Read file B
locking mode: either; action1: Create file A; action2: Update file B
locking mode: either; action1: Create file A; action2: Delete file B
locking mode: either; action1: Read file A; action2: Read file A
locking mode: either; action1: Read file A; action2: Read file B
locking mode: either; action1: Read file A; action2: Update file B
locking mode: either; action1: Read file A; action2: Delete file B
locking mode: either; action1: Update file A; action2: Update file B
locking mode: either; action1: Update file A; action2: Delete file B
locking mode: either; action1: Delete file A; action2: Delete file B
Error use-cases:
locking mode: either; action1: Create file A; action2: Create file A
locking mode: either; action1: Create file A; action2: Read file A
locking mode: either; action1: Create file A; action2: Update file A
locking mode: either; action1: Create file A; action2: Delete file A
locking mode: either; action1: Read file A; action2: Delete file A
locking mode: on; action1: Update file A; action2: Update file A
locking mode: either; action1: Update file A; action2: Delete file A
Problem use-cases:
locking mode: either; action1: Read file A; action2: Update file A
locking mode: off; action1: Update file A; action2: Update file A
locking mode: either; action1: Delete file A; action2: Delete file A
2I feel like there will be a 1 byte solution if I can just come up with the right input/output methods (maybe some kind of bit masking) – Expired Data – 2019-07-04T09:32:03.007
2@ExpiredData Altered a few parts of the possible outputs, that they have to be consistent, but not necessarily unique. And also that the inputs have to be consistent. – Kevin Cruijssen – 2019-07-04T09:35:39.803
1
@Arnauld Ah, I excluded all
– Kevin Cruijssen – 2019-07-04T12:52:46.240B/B
cases in my counting, since I deemed them similar asA/A
. That's where the difference is coming from. But I guess that thinking is incorrectly if you have a specific value for the files..