Fix: ProcessQueue throws truncated incorrect decimal value #1083
Conversation
The ProcessQueueCommand will pass a string for processId, which is stored as varchar. So the test should use a value that is a string with non-number characters.
|
@xyng Thank you so much for your contribution. Looks good at first glance. Will have the CI check the MySQL, MariaDB and PostgreSQL for us ;) There are some code-style, use statement sorting not right atm, but I think that is due to a rector update that isn't caused by you. So don't worry about those if the pipeline turns red. Update: Tests looks good in MySQL, MariaDB and PostgreSQL. Could you please update the PR to include a line in the CHANGELOG.md too ? |
processId is stored as varchar and stores strings. The SQL-Parameter is marked as integer, which can cause missed matches or runtime errors. Resolves: tomasnorre#1082
|
@tomasnorre thank you for checking and your feedback! |
The wording is fine. :) |
|
@xyng Thanks for your contribution, cannot say when it will be released. |
Description
This PR provides a test and fix for #1082 - changes the param-type of
processIdin the prepared statement tostringinstead ofinteger, since the database field already usesvarchar(50)andProcessQueueCommandwill pass a string.That can lead to either non-matches (sqlite) or even runtime errors (in one of our environments using MariaDB).
I have
Note
@tomasnorre I tried my best to get the test to reproduce. For some reason, only the SQLite one ran on my machine. For SQLite, there is no runtime error, but non-numeric values are not matched, leading the test case to fail the count-check which is somewhat sufficient to evaluate the problem.
I'd appreciate if you could check the MySQL and PostgreSQL derivates if they work correctly (either throw and exception or at least fail the count test).