Timeline for Drupal 7 db_insert() execute() error when table contains unique keys
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 3, 2019 at 8:17 | comment | added | Enno | This separation of validation and submission is one of my main gripes with Drupal. It's impossible to not introduce a race condition doing it that way: Say I have two requests going on at the same time. Request 1 checks that the ID does not exists, and validation passes. Then there is a task switch and request 2 does the same. Now both requests will try to insert the record, and whichever one comes last, runs into an exception. So even if you validated uniqueness with a SELECT, you still need to handle the exception (which, in a Drupal form_submit handler, is not easy to do). | |
| Apr 18, 2013 at 8:53 | comment | added | Clive♦ | That isn't a safe workflow though...no db transaction is started across the validation/submit handler calls so you introduce a potential race condition by presuming that the db result from the validate handler is still valid. I guess you could argue it's wise to use both methods, but the exception handler is an absolute must (as in any code, not just when dealing with db exceptions). I would agree with Neigyl R. Noval, though, that would be an unnecessary duplication of logic in this particular case (and it saves an extra db call in an already db-hungry Drupal app) | |
| Apr 18, 2013 at 8:46 | history | edited | jamix | CC BY-SA 3.0 |
Added extra explanation
|
| Apr 18, 2013 at 8:40 | comment | added | jamix | @Clive That's a valid point, but let's not forget the consideration of verifying the user input separately in the form validation handler as mentioned by kiamlaluno. | |
| Apr 18, 2013 at 7:51 | comment | added | Clive♦ | @Jamix Exception handling is always the preferred approach - trying to pre-empt exceptions is fine but it can very quickly get out of hand and clog up the codebase with unnecessary code and (in this case) database calls. Far better to let the exception workflow work exactly as the language dictates. Who's to say the exception would definitely be thrown by a duplicate key constraint? What about all the other things that can go wrong with a database statement? We use exceptions to handle these exceptional cases so we don't have to test for every possible error before we run a line of code | |
| Apr 18, 2013 at 1:55 | comment | added | Neigyl R. Noval |
I would also agree into this. But barcode is a unique_key in the table. So I expect MySQL does not accept duplicate entries and returns. Considering this answer, it would be like double defense (check if barcode already exists and the unique_key in MySQL) and the power of unique_key may become unused. What would be the advantage of checking first if barcode exists than using try...catch?
|
|
| Apr 17, 2013 at 22:44 | comment | added | avpaderno♦ | In a case like this, I would do as suggested in this answer, considering also that verifying the user input is a task of the form validation handler. | |
| Apr 17, 2013 at 20:52 | history | answered | jamix | CC BY-SA 3.0 |