Lock/unlock tables when editing entries #2585
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When editing an entry, Symphony will iterate over all fields, delete existing data first, then insert a new row for the field's data. So there will always be a time slot without field data. If multiple processes edit the same entry, this means a race condition that may lead to data being corrupted in several ways (also depending on the field type). Locking the table solves the issue. Fixes symphonycms#2472
| } | ||
|
|
||
| Symphony::Database()->insert($fields, 'tbl_entries_data_' . $field_id); | ||
| if ($did_lock) { |
There was a problem hiding this comment.
This block should be in a finally statement to be 100% kasher (if I am not wrong?)
There was a problem hiding this comment.
We discussed that some months ago (#2472 (comment)); the issue is that finally requires PHP 5.5+.
There was a problem hiding this comment.
I always forget about that. Thanks!
|
Thanks Michael. See my comments! |
|
I merge ASAP then! |
Closed
nitriques
added a commit
to DeuxHuitHuit/symphonycms
that referenced
this pull request
May 17, 2017
58bc57f added DISTINCT and LIMIT clauses to sub-queries used for sorts. The sub-query MUST return only one row, and (sometimes) it does not. See <INSERT REF HERE> As demonstrated by @michael-e, doing this does not suffice, since the php code also needs to change (or we would need to add more DISTINCT which is not better). The new table locking mechanism (symphonycms#2585) + making sure we update existing sites that are missing the unique key should prevent (hopefully) any data corroption before it can happen.
jensscherbl
pushed a commit
that referenced
this pull request
May 28, 2017
When editing an entry, Symphony will iterate over all fields, delete existing data first, then insert a new row for the field's data. So there will always be a time slot without field data. If multiple processes edit the same entry, this means a race condition that may lead to data being corrupted in several ways (also depending on the field type). Locking the table solves the issue. Fixes #2472
jensscherbl
pushed a commit
that referenced
this pull request
May 28, 2017
58bc57f added DISTINCT and LIMIT clauses to sub-queries used for sorts. The sub-query MUST return only one row, and (sometimes) it does not. See <INSERT REF HERE> As demonstrated by @michael-e, doing this does not suffice, since the php code also needs to change (or we would need to add more DISTINCT which is not better). The new table locking mechanism (#2585) + making sure we update existing sites that are missing the unique key should prevent (hopefully) any data corroption before it can happen.
nitriques
pushed a commit
that referenced
this pull request
Jun 16, 2017
When editing an entry, Symphony will iterate over all fields, delete existing data first, then insert a new row for the field's data. So there will always be a time slot without field data. If multiple processes edit the same entry, this means a race condition that may lead to data being corrupted in several ways (also depending on the field type). Locking the table solves the issue. Fixes #2472 Picked from 4b5067f
nitriques
added a commit
that referenced
this pull request
Jun 16, 2017
58bc57f added DISTINCT and LIMIT clauses to sub-queries used for sorts. The sub-query MUST return only one row, and (sometimes) it does not. See <INSERT REF HERE> As demonstrated by @michael-e, doing this does not suffice, since the php code also needs to change (or we would need to add more DISTINCT which is not better). The new table locking mechanism (#2585) + making sure we update existing sites that are missing the unique key should prevent (hopefully) any data corroption before it can happen. Picked from 86717ba
nitriques
pushed a commit
that referenced
this pull request
Jun 16, 2017
When editing an entry, Symphony will iterate over all fields, delete existing data first, then insert a new row for the field's data. So there will always be a time slot without field data. If multiple processes edit the same entry, this means a race condition that may lead to data being corrupted in several ways (also depending on the field type). Locking the table solves the issue. Fixes #2472 Picked from 4b5067f
nitriques
added a commit
that referenced
this pull request
Jun 16, 2017
58bc57f added DISTINCT and LIMIT clauses to sub-queries used for sorts. The sub-query MUST return only one row, and (sometimes) it does not. See <INSERT REF HERE> As demonstrated by @michael-e, doing this does not suffice, since the php code also needs to change (or we would need to add more DISTINCT which is not better). The new table locking mechanism (#2585) + making sure we update existing sites that are missing the unique key should prevent (hopefully) any data corroption before it can happen. Picked from 86717ba
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When editing an entry, Symphony will iterate over all fields, delete existing data first, then insert a new row for the field's data. So there will always be a time slot without field data. If multiple processes edit the same entry, this means a race condition that may lead to data being corrupted in several ways (also depending on the field type). Locking the table solves the issue.
Fixes #2472