-
-
Notifications
You must be signed in to change notification settings - Fork 17
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
Fix sql ast type inference on raw-sql expression without aliases #582
Fix sql ast type inference on raw-sql expression without aliases #582
Conversation
…into failing-ast-column-recognition
…to failing-ast-column-recognition
Hey @jakubvojacek, thanks for working on this! I'm looking forward to this fix, as it's a big factor holding me back from enabling SQL AST. One thing I noticed is that a lot of the existing tests assert the wrong types due to this bug, so we don't actually want them to pass without being modified (to the best of my knowledge). I've documented some of the examples in #578. My apologies if I've commented before you were done with the PR! |
Hello @hemberger, I believe this PR is ready. Which of the tests that are now passing shouldn't be? I checked with the sample
and the expected output in this PR would be Thanks |
Since
Looking at the stmt = $pdo->query('SELECT max(freigabe1u1) as max from ada');
assertType('PDOStatement<array{max: int<-128, 127>|null, 0: int<-128, 127>|null}>', $stmt); The expected type should be:
because the
I think many of the aggregate functions are still wrong (e.g. avg, sum, min, max). Maybe that means there is a bug somewhere outside this PR, but something somewhere seems not quite right. I wonder if it would be helpful to test the queries with and without the aliases, as well? Thanks again for your work here. Can't wait to use it! :) |
that is most likely it. This PR only fixed that a column with an alias has same output as without it, eg -assertType('PDOStatement<array{myemail: int<0, max>|null, 0: int<0, max>|null, count(email): int, 1: int<0, max>|null}>', $stmt);
+assertType('PDOStatement<array{myemail: int<0, max>|null, 0: int<0, max>|null, count(email): int<0, max>|null, 1: int<0, max>|null}>', $stmt); After this PR, But you're right it seems, freigabe1u1 is a small signed int and the range is incorrect there, right @staabm ? But that should be addressed by another PR I guess? |
@staabm @hemberger I narrowed the problem down to MysqlTypeMapper (https://github.com/staabm/phpstan-dba/blob/main/src/TypeMapping/MysqlTypeMapper.php#L96) It resolves the range based on display width (length) which isnt correct apparently. It should be done based on native_type? Below is a sample of the
https://dev.mysql.com/doc/refman/8.0/en/numeric-type-attributes.html
|
Please open a new issue with the posted findings We should only fix 1 problem with this PR |
yes of course, I can try & send a new PR for the mapper As for this PR, is it ready or you still have some doubts? |
use PHPStan\Testing\TypeInferenceTestCase; | ||
use function getenv; | ||
|
||
class DbaInferenceTest extends TypeInferenceTestCase |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should rename the test-suite fro defaultAst
to sqlAst
and the test from DbaInferenceTest
to SqlAstInferenceTest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
thank you |
I tried to revive the old branch in order to get back to the solution that worked (as per #580 (comment)), lets see whether the tests go through