io.getquill.context

Metadata related to query execution. Note that AST should be lazy so as not to be evaluated at runtime (which would happen with a by-value property since { ExecutionInfo(stuff, ast) } is spliced into a query-execution site). Additionally, there are performance overheads even splicing the finalized version of the AST into call sites of therun` functions. For this reason, this functionality is being used only in ProtoQuill and only when a trait extends the trait AstSplicing. In the future it might potentially be controlled by a compiler argument.

While many databases allow multiple VALUES clauses, they do not support doing getGeneratedKeys or allow returning clauses for those situations (or actually do not fail but just have wrong behavior e.g. Sqlite.) This context controls which DBs can do batch-insert and actually return the generated IDs from the batch inserts (currently only Postgres and SQL Server can do this).

The DB supports multiple values-clauses per insert-query

The DB supports only one single values-clauses per insert-query

Whether values-clause in INSERT INTO Someplaces (...) VALUES (values-clause) can be repeated i.e: INSERT INTO Someplaces (...) VALUES (values1), (values2), (values3), etc...

An actual OUTPUT clause is supported in the SQL dialect of the specified database e.g. MSSQL Server. this typically means that columns returned from Insert/Update/etc... clauses can have arithmetic operations done on them such as OUTPUT INSERTED.id + 1.

A common context used between Quill and ProtoQuill. This is more like a pre-context because the actual run methods cannot be contained here since they use macros. Right now not all Scala2-Quill context extend this context but hopefully they will all in the future. This will establish a common general-api that Quill contexts can use. In ProtoQuill, this context is used for the base of all other context and allows the Scala 3 macros to call the execute___ methods. In Scala2-Quill wherein macros are less strict about signatures, this cannot be used for Context (in Context.scala) but various higher-level context extend it as a guard-rail against API drift i.e. so that the Scala2-Quill and ProtoQuill internal-context APIs remain largely the same.

An actual RETURNING clause is supported in the SQL dialect of the specified database e.g. Postgres. this typically means that columns returned from Insert/Update/etc... clauses can have other database operations done on them such as arithmetic RETURNING id + 1, UDFs RETURNING udf(id) or others. In JDBC, the following is done: connection.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS)).

Returning multiple columns from Insert/Update/etc... clauses is supported. This generally means that columns besides auto-incrementing ones can be returned. This is supported by Oracle. In JDBC, the following is done: connection.prepareStatement(sql, Array("column1, column2, ...")).

Data cannot be returned Insert/Update/etc... clauses in the target database.

Returning a single field from Insert/Update/etc... clauses is supported. This is the most common databases e.g. MySQL, Sqlite, and H2 (although as of h2database/h2database#1972 this may change. See #1496 regarding this. Typically this needs to be setup in the JDBC connection.prepareStatement(sql, Array("returnColumn")).