Skip to content

v1.0.0-beta.28

Choose a tag to compare

@justinvdm justinvdm released this 17 Nov 09:53
· 634 commits to main since this release

What's Changed

  • docs: Documents How To Send and Receive using Cloudflare Email Workers by @dthyresson in #874
  • docs: Updates to Cloudflare Email handling documentation by @dthyresson in #877
  • Avoid rendering current docs hover color with background color by @valscion in #879
  • useSyncState hook. by @peterp in #871
  • fix(db): Infer column nullability correctly for rwsdk/db by @kcc989 in #878
  • fix: Ensure hoisted meta tags are correctly placed in document head by @justinvdm in #885

⚠️ Breaking Change: Database Type Inference for Nullable Columns is Now Correct

This release corrects a fundamental issue in the rwsdk/db type inference system where columns were incorrectly inferred as non-nullable by default. The system now correctly aligns with SQL standards, where columns are nullable unless explicitly constrained.

What is the change?

  • Previous Behavior: All columns were typed as non-nullable (e.g., string, number) unless you were using a version that had partial fixes.
  • New Behavior: Columns are now correctly inferred as nullable by default (e.g., string | null, number | null). A column will only be non-nullable if it has a .notNull(), .primaryKey(), or .defaultTo() constraint in its migration definition.

Why is this a breaking change?

This change fixes a bug in the type system. If your application code was written relying on the previously incorrect non-nullable types, you may now see new TypeScript errors.

These errors are not new bugs. They are surfacing legitimate type mismatches that were previously hidden by the incorrect inference. Your code may have been vulnerable to runtime errors if the database returned a null value that the type system did not account for.

How to update your code

You will need to update any code that interacts with nullable columns to correctly handle the possibility of null values. The TypeScript errors will guide you to the exact locations.

For example, if you have a users table where the bio column is nullable:

// src/db/migrations.ts
// ...
  .createTable("users")
  .addColumn("id", "text", (col) => col.primaryKey())
  .addColumn("bio", "text") // This is nullable by default
// ...

Your application code might now show a type error:

import { db } from "@/db";

const user = await db.selectFrom("users").selectAll().executeTakeFirst();

// 🚨 ERROR: 'user.bio' is possibly 'null'.
// Type 'string | null' is not assignable to type 'string'.
const bioLength: number = user.bio.length;

To fix this, add a null check before accessing the property:

import { db } from "@/db";

const user = await db.selectFrom("users").selectAll().executeTakeFirst();

// ✅ Correct: Handle the null case
const bioLength: number = user.bio ? user.bio.length : 0;

By making these adjustments, your application will be more robust and correctly typed against the actual schema of your database.

Full Changelog: v1.0.0-beta.27...v1.0.0-beta.28