-
Notifications
You must be signed in to change notification settings - Fork 20
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
Add support for Microsoft SQL #29
base: main
Are you sure you want to change the base?
Conversation
Can UTF-8 support be opted-in? This post seems to indicate it should be available https://techcommunity.microsoft.com/t5/sql-server-blog/introducing-utf-8-support-for-sql-server/ba-p/734928 |
That's the thing. I did try that by setting |
The code changes look reasonable. In terms of flakiness, perhaps we need to do a |
@lihaoyi Question about the sorting tests with nulls under SELECT opt_cols0.my_int AS my_int, opt_cols0.my_int2 AS my_int2
FROM opt_cols opt_cols0
ORDER BY my_int NULLS LAST the defined accepted result is value = Seq(
OptCols[Sc](Some(1), Some(2)),
OptCols[Sc](Some(3), None),
OptCols[Sc](None, None),
OptCols[Sc](None, Some(4))
) but shouldn't value = Seq(
OptCols[Sc](Some(1), Some(2)),
OptCols[Sc](Some(3), None),
OptCols[Sc](None, Some(4)),
OptCols[Sc](None, None)
) also be acceptable since we only order by |
@kiendang yes that should be acceptable. IIRC the test suite allows a |
Use `SELECT TOP(?) ...` for MS SQL when there's no offset.
Adapted The UTF-8 workaround fixed around 40 tests. There are still around 93 failed tests out of 310. A large number of those are due to MS SQL does not have a boolean type. You can only use boolean expression in the This is legal SELECT * FROM buyer WHERE name IS NOT NULL; These are not CREATE TABLE tb (
x BOOLEAN
);
SELECT name IS NOT NULL FROM buyer;
SELECT * FROM buyer ORDER BY name IS NOT NULL; Instead have to do CREATE TABLE tb (
x BIT
);
SELECT IIF(name IS NOT NULL, 1, 0) FROM buyer;
SELECT * FROM buyer ORDER BY IIF(name IS NOT NULL, 1, 0); |
Sounds good. Generating |
The built-in LogMessageWaitStrategy doesn't work.
It's a bit more involved than just overriding |
Having custom serialization in the SELECT clause only is doable, as we control the entire query serialization pipeline, but how invasive it would be depends on exactly what semantics you need to introduce. Is |
Boolean expressions can only be used as conditions, not values. These are legal WHERE x > 3
CASE WHEN x > 3 These are not SELECT x > 3
ORDER BY x > 3
GROUP BY x > 3
-- this is also illegal because `x > 3` is used as value here
WHERE (x > 3) = (x > 3) Another issue is boolean literals don't exists either, so these currently fail |
And how anout as parameters to functions? Like booleans are allowed as parameters to iif, but how about other sql functions? Maybe one thing to do here is to look into how Slick and Quill handle this. IIRC both of those libraries support mssql server, and their handling may give us some idea of the best way to proceed for scalasql |
Can't find anything related to MSSQL functions taking boolean inputs but my guess is that Quill does render boolean values as https://scastie.scala-lang.org/kiendang/XHfKDq7jRmS0NwFEAC18pQ/25 |
Would following Quill's strategy work? Presumably if it works for Quill well enough for people to depend on it it should work for Scalasql as well |
Seems like SLICK treats all booleans as bits as well https://github.com/slick/slick/blob/c4b081da7996ad74ccc707d139b07c11c2eb6bba/slick/src/main/scala/slick/jdbc/SQLServerProfile.scala#L316 I guess thats what we need to do in ScalaSql. If the library doesnt already provide appropriate hooks to override, we'll have to add them |
Close #17.
Not complete yet. Most test failures are due to MS SQL does not use UTF-8 for strings. Need to figure that out.