Add DuckDB support to Typo code generator (#168)

* Add DuckDB support to Typo code generator

This commit introduces comprehensive DuckDB support to Typo, extending the
type-safe code generator to work with DuckDB's unique type system and SQL
dialect alongside existing PostgreSQL and MariaDB support.

## DuckDB Type System Modeling

DuckDB provides several type system features not present in PostgreSQL or
MariaDB:

1. **Unsigned Integer Types**: UTINYINT, USMALLINT, UINTEGER, UBIGINT,
   UHUGEINT mapped to Kotlin's UByte, UShort, UInt, ULong, and BigInteger

2. **Nested/Complex Types**:
   - LIST: Array-like collections with element type
   - MAP: Key-value maps with typed keys and values
   - STRUCT: Named field structures
   - UNION: Tagged union types

3. **Temporal Type Variations**: TIMESTAMP_S, TIMESTAMP_MS, TIMESTAMP_NS
   with different precision levels

These types are modeled in the db.scala type hierarchy and mapped to
appropriate Java/Kotlin/Scala runtime types in DuckDbAdapter.scala.

## SQL Dialect Differences

DuckDB's SQL dialect differs from PostgreSQL and MariaDB in several ways,
handled through the Dialect abstraction:

1. **Identifier Quoting**: Uses double quotes like PostgreSQL, unlike
   MariaDB's backticks

2. **Type Casts**: Uses PostgreSQL-compatible :: syntax rather than
   CAST() function

3. **Column References**: Simple alias."column" format, not PostgreSQL's
   (alias)."column" format

4. **Array Parameter Syntax**: Arrays use DuckDB-specific syntax:
   - PostgreSQL: ARRAY[?, ?, ...]::type[]
   - DuckDB: [?, ?, ...]

## Runtime Type System

Added comprehensive runtime support in typo-runtime-java:

- **DuckDbType**: Type class providing read/write/stringify/json support
- **DuckDbRead**: ResultSet reading with nested type support (LIST, STRUCT, MAP)
- **DuckDbWrite**: PreparedStatement parameter binding
- **DuckDbStringifier**: SQL literal encoding for code generation
- **DuckDbTypename**: Type name abstraction with conversions

## Kotlin Nullable Type Handling

Fixed a type system mismatch between Java Optional and Kotlin nullable types:

**Problem**: The Kotlin .nullable() extension was using .bimap() which called
.map() on Nullable readers. This returned NonNullable<B> where B = A?, but
NonNullable throws SQLException when B is null. For Kotlin, null is a valid
value in the type system.

**Solution**: Created KotlinNullableDuckDbRead and KotlinNullableMariaRead
that handle nullable values natively:
- Wrap the underlying opt() reader
- Convert Optional.empty() → null and Optional.of(value) → value
- Return A? without NonNullable validation
- Implement DbRead.Nullable marker interface

This respects the different null handling semantics:
- Java/Scala: Non-nullable values guaranteed by construction
- Kotlin: Nullable values (T?) are natural in the type system

## Code Generation

Extended code generation in DbLibTypo.scala and DuckDbAdapter.scala:
- Repository implementations for Java, Kotlin, and Scala
- Row classes with proper unsigned type mapping
- RowParser lambdas without unnecessary !! assertions
- Test insert generation with DuckDB-specific types

## Testing

All test suites passing:
- Java DuckDB tests: 56/56 (AllScalarTypesTest, RepositoryTest, etc.)
- Kotlin DuckDB tests: 53/53 (AllScalarTypesTest, CompositeIdTest,
  RepositoryTest, SqlFileArrayTest)

Generated code checked into:
- typo-tester-duckdb-java/generated-and-checked-in/
- typo-tester-duckdb-kotlin/generated-and-checked-in/
- typo-tester-duckdb-scala/generated-and-checked-in/

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <[email protected]>

* Fix Kotlin nullable type handling and Scala 3 lambda generation

- Fix PgRead.Nullable.map() to use Optional.ofNullable() for Kotlin null support
- Generate explicit lambda for Scala 3 and TypeSupportJava to avoid LambdaConversionException
- Fixes NullPointerException in Kotlin PostgreSQL tests
- Fixes BootstrapMethodError in Scala 3 tests

* Fix Scala 3 lambda pattern matching - always generate lambda for LangScala

The previous pattern '_: LangScala | _ if lang.typeSupport == TypeSupportJava' was incorrect -
it only matched when typeSupport == TypeSupportJava, missing regular Scala 3 tests.

Now generates explicit lambda for:
- All LangScala (fixes >22 param limit and Scala 3 LambdaConversionException)
- TypeSupportJava
- Kotlin (already working)

Method references don't work for >22 params in Scala due to Function22 limit.

* wip

* Regenerate code with Scala 3 lambda fix for >22 parameter tables

Generated code now uses explicit lambdas instead of constructor method
references for RowParser, which fixes Scala 3 LambdaConversionException
on tables with many columns like production.product (25 params).

Also includes the Optional.ofNullable() fix for Kotlin nullable types.

* Format generated code with scalafmt

* wip

---------

Co-authored-by: Claude Sonnet 4.5 <[email protected]>

Author: oyvindberg

.bleep/generated-sources/typo-tester-typo-java/scripts.GenHardcodedFiles/testdb/hardcoded/compositepk/person/PersonRow.java

@@ -36,7 +36,7 @@ public PersonRow withName(Optional<String> name) {
     return new PersonRow(one, two, name);
   };
 
-  static RowParser<PersonRow> _rowParser = RowParsers.of(PgTypes.int8, PgTypes.text.opt(), PgTypes.text.opt(), PersonRow::new, row -> new Object[]{row.one(), row.two(), row.name()});;
+  static RowParser<PersonRow> _rowParser = RowParsers.of(PgTypes.int8, PgTypes.text.opt(), PgTypes.text.opt(), (t0, t1, t2) -> new PersonRow(t0, t1, t2), row -> new Object[]{row.one(), row.two(), row.name()});;
 
   static public PersonRow apply(
     PersonId compositeId,

.bleep/generated-sources/typo-tester-typo-java/scripts.GenHardcodedFiles/testdb/hardcoded/myschema/football_club/FootballClubRow.java

@@ -26,7 +26,7 @@ public FootballClubRow withName(String name) {
     return new FootballClubRow(id, name);
   };
 
-  static RowParser<FootballClubRow> _rowParser = RowParsers.of(FootballClubId.pgType, PgTypes.text, FootballClubRow::new, row -> new Object[]{row.id(), row.name()});;
+  static RowParser<FootballClubRow> _rowParser = RowParsers.of(FootballClubId.pgType, PgTypes.text, (t0, t1) -> new FootballClubRow(t0, t1), row -> new Object[]{row.id(), row.name()});;
 
   static public PgText<FootballClubRow> pgText =
     PgText.from(_rowParser);

.bleep/generated-sources/typo-tester-typo-java/scripts.GenHardcodedFiles/testdb/hardcoded/myschema/marital_status/MaritalStatusRow.java

@@ -17,7 +17,7 @@ public MaritalStatusRow withId(MaritalStatusId id) {
     return new MaritalStatusRow(id);
   };
 
-  static RowParser<MaritalStatusRow> _rowParser = RowParsers.of(MaritalStatusId.pgType, MaritalStatusRow::new, row -> new Object[]{row.id()});;
+  static RowParser<MaritalStatusRow> _rowParser = RowParsers.of(MaritalStatusId.pgType, t0 -> new MaritalStatusRow(t0), row -> new Object[]{row.id()});;
 
   static public PgText<MaritalStatusRow> pgText =
     PgText.from(_rowParser);

.bleep/generated-sources/typo-tester-typo-java/scripts.GenHardcodedFiles/testdb/hardcoded/myschema/person/PersonRow.java

@@ -101,7 +101,7 @@ public PersonRow withFavoriteNumber(Number favoriteNumber) {
     return new PersonRow(id, favouriteFootballClubId, name, nickName, blogUrl, email, phone, likesPizza, maritalStatusId, workEmail, sector, favoriteNumber);
   };
 
-  static RowParser<PersonRow> _rowParser = RowParsers.of(PersonId.pgType, FootballClubId.pgType, PgTypes.text, PgTypes.text.opt(), PgTypes.text.opt(), PgTypes.text, PgTypes.text, PgTypes.bool, MaritalStatusId.pgType, PgTypes.text.opt(), Sector.pgType, Number.pgType, PersonRow::new, row -> new Object[]{row.id(), row.favouriteFootballClubId(), row.name(), row.nickName(), row.blogUrl(), row.email(), row.phone(), row.likesPizza(), row.maritalStatusId(), row.workEmail(), row.sector(), row.favoriteNumber()});;
+  static RowParser<PersonRow> _rowParser = RowParsers.of(PersonId.pgType, FootballClubId.pgType, PgTypes.text, PgTypes.text.opt(), PgTypes.text.opt(), PgTypes.text, PgTypes.text, PgTypes.bool, MaritalStatusId.pgType, PgTypes.text.opt(), Sector.pgType, Number.pgType, (t0, t1, t2, t3, t4, t5, t6, t7, t8, t9, t10, t11) -> new PersonRow(t0, t1, t2, t3, t4, t5, t6, t7, t8, t9, t10, t11), row -> new Object[]{row.id(), row.favouriteFootballClubId(), row.name(), row.nickName(), row.blogUrl(), row.email(), row.phone(), row.likesPizza(), row.maritalStatusId(), row.workEmail(), row.sector(), row.favoriteNumber()});;
 
   static public PgText<PersonRow> pgText =
     PgText.from(_rowParser);

.gitignore

@@ -17,3 +17,5 @@ out/
 build/
 .typo/
 __pycache__/
+testdb
+testdb.wal

CLAUDE.md

@@ -375,6 +375,10 @@ When working on Typo issues, follow this workflow:
 ### Memories
 - **NEVER REPORT SUCCESS IF ITS NOT A SUCCESS.**
 - never ever use default parameters for anything
+<<<<<<< HEAD
 - UNDER NO CIRCUMSTANCES ARE YOU USING UNTYPED HTTP CLIENTS WHEN IMPLEMENTING INTEGRATION TESTS. WE ARE TESTING GENERATED CODE IN BOTH ENDS HERE
 - always run bleep with --no-color
-- YOU ARE NOT UNDER ANY CIRCUMSTANCE ALLOWED TO CAST TO CHEAT THE TYPE SYSTEM. IF YOU COME ACROSS A SITUATION WHERE YOU HAVE NO OTHER CHOICE, STOP AND ASK USER
+- YOU ARE NOT UNDER ANY CIRCUMSTANCE ALLOWED TO CAST TO CHEAT THE TYPE SYSTEM. IF YOU COME ACROSS A SITUATION WHERE YOU HAVE NO OTHER CHOICE, STOP AND ASK USER
+=======
+- UNDER NO CIRCUMSTANCES ARE YOU USING UNTYPED HTTP CLIENTS WHEN IMPLEMENTING INTEGRATION TESTS. WE ARE TESTING GENERATED CODE IN BOTH ENDS HERE
+>>>>>>> f462a4abf3 (Add comprehensive DuckDB support for Typo)