Main future branch

[belamenso]

No description provided.

[belamenso]

I've copied over basic test to see if we have a connection.
Adding the dependencies on the DB drivers did significantly increase the time it takes to sbt update from a clean state.

[belamenso]

@aherlihy Why did you decide on this specific munit version?
"org.scalameta" %% "munit" % "1.0.0+24-ee555b1d-SNAPSHOT" % Test,

[belamenso]

@aherlihy This is the compile-time error message that happens when a user wants to use a dialect feature that was not defined for the current dialect:

-- [E172] Type Error: /app/src/test/scala/test/integration/random.scala:60:39 --
60 |      check(t.map(_ => Expr.randomFloat()).toQueryIR.toSQLString())(withDBNoImplicits.sqlite)
   |                                       ^
   |No given instance of type tyql.DialectFeature.RandomFloat was found for parameter r of method randomFloat in object Expr
   |
   |One of the following imports might fix the problem:
   |
   |  import tyql.Dialect.duckdb.given_RandomFloat
   |  import tyql.Dialect.h2.given_RandomFloat
   |  import tyql.Dialect.mariadb.given_RandomFloat
   |  import tyql.Dialect.mysql.given_RandomFloat
   |  import tyql.Dialect.postgresql.given_RandomFloat
   |

What do you think of the readability of this? We could define it as something that fails at runtime, but then the compiler will not error and the IDE will not draw red lines under incorrect code. What do you think?

It tell you which dialects have it, but it a shame that it does not show you somehow the current dialect (but that's in the source code unless you're using ANSI SQL which is the default).

[belamenso]

On my laptop I sometimes get this error when running tests

java.sql.SQLException: No suitable driver found for jdbc:postgresql://localhost:5433/testdb
    at java.sql.DriverManager.getConnection(DriverManager.java:708)
    at java.sql.DriverManager.getConnection(DriverManager.java:230)

but this happens only on my laptop, it works perfectly on Docker. If you see this, it's not a problem, I think.

[belamenso]

GitHub CI is already enabled on this branch: https://github.com/belamenso/tyql/tree/better-containerization

These tests run for around ~3 minutes (mostly installing). This could perhaps be optimized, but I don't know Docker/docker-compose well enough for now.

[belamenso]

@aherlihy Questions is, what to do with equality and null-safe equality. Postgres and DuckDB and H2 will fail at runtime when you try to compare things that are not of the same type affinity (!). Our options

• make equalities only between the same type affinities
• make equalities universal and fail at runtime in these special DBs
• make equalities universal except for these two dialects, where they are only between the same type affinities
• polyfill these special DBs somehow, ideally only for questionable type combinations

Example things that fail at runtime in Postgres:

• select 'b' is not distinct from 10
• select 'a' = 10

For now what you can compare is fully dialect-dependent.

[belamenso]

The main branch of my fork is now on main, I close this pull-request and will open another.