2.0.0-beta1 feedback

[beverloo]

Hi Juan!

2.0.0 looks great! I had a play around with the beta today and ran into three minor issues that I wanted to share. All were straightforward to work around. (commit)

To be clear, I'm not requesting any changes, I only wanted to provide some signal :)

buildFragmentWithArgs w/ noTableOrViewRequired

The buildFragmentWithArgs method on a connection no longer seems to allow argument-less fragments that don't require a table or view. Take the following example:

export class MyConnection extends MariaDBConnection<'DBConnection'> {
  currentZonedDateTime = this.buildFragmentWithArgs().as(() =>
    this.fragmentWithType<ZonedDateTime>('customLocalDateTime', 'ZonedDateTime', 'required')
        .sql`current_timestamp`);
}

This now triggers the following TypeScript error:

Type 'CustomLocalDateTimeValueSource<"mariaDB:MyConnection/noTableOrViewRequired/", ZonedDateTime, ZonedDateTime, "required">' is not assignable to type 'ValueSourceOf<"mariaDB:MyConnection/">'.
  Types of property '[source]' are incompatible.
    Type '"mariaDB:MyConnection/noTableOrViewRequired/"' is not assignable to type '"mariaDB:MyConnection/"'.ts(2322)

The following workaround seems to work well, but I still found it a bit surprising as the zero-argument variant of buildFragmentWithArgs exists, which is recommended for reusable fragments.

currentZonedDateTime = () =>
    this.fragmentWithType<ZonedDateTime>('customLocalDateTime', 'ZonedDateTime', 'required')
        .sql`current_timestamp`;

Nested projections can now be null

Take the following select:

const result = await db.selectFrom(tEvents)
    .where(tEvents.eventId.equals(100))
    .select({
        group: {
            column: tEvents.eventLocation,  // nullable column
        },
    })
    .executeSelectOne();

This evalutes to the following types:

• 1.x: { group?: { column: string | undefined } | undefined }
• 2.0: { group?: { column: string | undefined } | null | undefined }

I'm curious why null is significant, and how it differs from undefined?

I've tried a few things to try to trigger a null value, but without success. (group either has a value or is omitted altogether, so practically speaking the behaviour matches { group?: { column: string } } but that'd really complex to type.)

ExecutableInsert & friends not being exported anymore

Technically they're still in the "__UNSUPPORTED__" directory though :P

I used these to effectively compose a complicated transaction, the mutations in which have to be decided upon as part of a complicated diffing process with the following output:

interface Mutations {
    created: ExecutableInsert<typeof tEvents, any>[],
    updated: ExecutableUpdate<typeof tEvents, any>[],
    deleted: ExecutableUpdate<typeof tEvents, any>[],
}

I suppose that I was holding this wrong, and that the recommended approach would be to apply low-level transaction management here? I.e.

try {
    await db.beginTransaction();
    // Decide on and immediately execute all mutations
    await db.commit();
catch (error) {
    await db.rollback();
}

[juanluispaz]

Hi,

Thanks for take the time and review the beta.

Regarding buildFragmentWithArgs w/ noTableOrViewRequired: Already fixed in 4d6f1de (2026-06-16) few days after the first beta, as part of detecting some invalid queries.

Regarding Nested projections can now be null: Ups, that wrong and introduced during the refactor of v2, I just fixed it at 65f60bc

Regarding ExecutableInsert & friends not being exported anymore: maybe I need to create a stable surface for it. I've been reviewing your code to try to understand what are you trying to archive with it, if you give he some hints I will appreciate it.

__UNSUPPORTED__ is there when things get more complicated, but, due SQL is massive, it is hard to commit stability in all types and at the same time continue expanding the SQL capabilities, previously was documented, now I am making it more visible.

There is something that I'm not getting, why need you the unexecuted query instead of a function that executes that query?

Le me put in code:

interface Mutations {
    created: Array<() => Promise<unknown>>,
    updated: Array<() => Promise<unknown>>,
    deleted: Array<() => Promise<unknown>>,
    // ...
}

and then have:

 await dbInstance.transaction(async () => {
                for (const createQuery of mutations.created)
                    await createQuery();
                for (const updateQuery of mutations.updated)
                    await updateQuery();
                for (const deleteQuery of mutations.deleted)
                    await deleteQuery();

and then register your queries as:

 mutations.deleted.push(() => dbInstance.update(tActivities)
                    .set({
                        activityDeleted: dbInstance.currentZonedDateTime(),
                    })
                    .where(tActivities.activityId.equals(activityId)))
                    .executeUpdate());

That give you far more control and flexibility.

Changes have not been published yet, I will be publishing new betas.

The final version 2 will be published when:

• code coverage to almost fully covered the library from line and branches perspectives, as well from types perspectives. 
• There is one refactor still on going to allow to have type extensibility, that means is far easier to add new types, as well for the ts-sql-query' users, where the type can have additional functions inside the type. This will make it possible to add full build in temporal support, and eventually geometrical types.