BA
Better Auth•3w ago
acusti

Latest CLI changes drizzle datetime fields from mode: 'timestamp' → mode: 'timestamp_ms'

@Better Auth i’m using drizzle + cloudflare D1 and i added some user.additionalFields to my config, so i ran npx @better-auth/cli generate and all the existing datetime fields were changed from a unix timestamp in seconds to a unix timestamp in milliseconds. here’s a representative example extracted from session, with before: 
    expiresAt: integer('expires_at', { mode: 'timestamp' }).notNull(),
    expiresAt: integer('expires_at', { mode: 'timestamp' }).notNull(),
and after: 
    expiresAt: integer('expires_at', { mode: 'timestamp_ms' }).notNull(),
    expiresAt: integer('expires_at', { mode: 'timestamp_ms' }).notNull(),
the createdAt/updatedAt also include new default/onupdate logic, which seems pretty straightforward. before: 
    createdAt: integer('created_at', { mode: 'timestamp' }).notNull(),
    updatedAt: integer('updated_at', { mode: 'timestamp' }).notNull(),
    createdAt: integer('created_at', { mode: 'timestamp' }).notNull(),
    updatedAt: integer('updated_at', { mode: 'timestamp' }).notNull(),
and after: 
    createdAt: integer('created_at', { mode: 'timestamp_ms' })
        .default(sql`(cast(unixepoch('subsecond') * 1000 as integer))`)
        .notNull(),
    updatedAt: integer('updated_at', { mode: 'timestamp_ms' })
        .$onUpdate(() => /* @__PURE__ */ new Date())
        .notNull(),
    createdAt: integer('created_at', { mode: 'timestamp_ms' })
        .default(sql`(cast(unixepoch('subsecond') * 1000 as integer))`)
        .notNull(),
    updatedAt: integer('updated_at', { mode: 'timestamp_ms' })
        .$onUpdate(() => /* @__PURE__ */ new Date())
        .notNull(),
i tried generating a drizzle migration based on the changes, and it doesn’t look like the existing timestamps are being migrated (no SET createdAt = createdAt * 1000 or the like). here’s the excerpt for the session table: 
INSERT INTO `__new_session`("active_organization_id", "active_team_id", "created_at", "expires_at", "id", "ip_address", "token", "updated_at", "user_agent", "user_id") SELECT "active_organization_id", "active_team_id", "created_at", "expires_at", "id", "ip_address", "token", "updated_at", "user_agent", "user_id" FROM `session`;--> statement-breakpoint
DROP TABLE `session`;--> statement-breakpoint
ALTER TABLE `__new_session` RENAME TO `session`;--> statement-breakpoint
CREATE UNIQUE INDEX `session_token_unique` ON `session` (`token`);--> statement-breakpoint
INSERT INTO `__new_session`("active_organization_id", "active_team_id", "created_at", "expires_at", "id", "ip_address", "token", "updated_at", "user_agent", "user_id") SELECT "active_organization_id", "active_team_id", "created_at", "expires_at", "id", "ip_address", "token", "updated_at", "user_agent", "user_id" FROM `session`;--> statement-breakpoint
DROP TABLE `session`;--> statement-breakpoint
ALTER TABLE `__new_session` RENAME TO `session`;--> statement-breakpoint
CREATE UNIQUE INDEX `session_token_unique` ON `session` (`token`);--> statement-breakpoint
is there application logic to ensure that i can make this change and everything will still work seemlessly?
3 Replies
Better Auth
Better Auth•3w ago
Based on the current Better Auth behavior, the CLI now produces schema changes that use millisecond precision (timestamp_ms) with new default and on-update logic for fields like createdAt, updatedAt, and expiresAt [12]. However, this migration only affects the generated schema—there isn’t built‐in application logic that automatically converts your existing timestamp values from seconds to milliseconds. That means if you update your schema with these new definitions, existing records (stored in seconds) won’t be automatically scaled. You’ll need to handle a data migration (for example, by updating the stored values with a factor of 1000) so that the timestamps match the new precision. After you run such a migration, all new and existing timestamps will be consistent, and your authentication flows should work seamlessly. If you’re using Cloudflare D1 (which is SQLite-based), double-check that your migration script includes the needed conversion steps for your timestamp columns. This extra manual step will help ensure that your application continues to work as expected after the schema change [12]. Sources: [12] v1.3.24
GitHub
Build software better, together
GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.
From An unknown user
From An unknown user
From An unknown user
GitHub
v1.3.24 by himself65 · Pull Request #4976 · better-auth/better-auth
Summary by cubic Refreshes cached sessions in secondary storage when a user is updated, so changes like emailVerified propagate to all active sessions. Also fixes DB schema handling for onDelete an...
acusti
acustiOP•3w ago
@Better Auth thanks for that explanation! i’m currently using v1.3.26 in my application, but i still have the same second-precision timestamps in my DB, and everything seems to work fine. is that because drizzle is managing the conversion so that better-auth sees the same thing in the end? also, my current schema’s updatedAt fields don’t have the $onUpdate function (.$onUpdate(() => /* @__PURE__ */ new Date())), but i haven’t noticed them being incorrect, so i assume there’s another way that’s being handled?
Better Auth
Better Auth•3w ago
Hi there! It sounds like you’re observing expected behavior. Even though your DB stores second‑precision timestamps, Drizzle automatically converts those values into proper Date objects so that Better Auth works with them seamlessly [1]. Additionally, while earlier schema generations explicitly added the .$onUpdate hook for fields like updatedAt, recent changes (and some internal update logic) mean that Better Auth now ensures the updatedAt field is refreshed during updates without solely relying on the DB-level $onUpdate function [2][3]. In short, even without seeing the function in your schema, your application remains fully in sync because the adapter and update routines take care of it behind the scenes. Sources: [1] feat: add onUpdate field on db schema generation [2] $onUpdate is not set for updatedAt field in psql schema [3] fix: schema onUpdate not working
GitHub
Build software better, together
GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.
From An unknown user
From An unknown user
From An unknown user
GitHub
feat: add onUpdate field on db schema generation by himself65 · ...
Fixes: DEV-247 Fixes: #4187 Summary by cubic Adds onUpdate support to schema generation so timestamp fields (like updatedAt) auto-update across PostgreSQL, MySQL, and SQLite. Generated Drizzle sch...
GitHub
$onUpdate is not set for updatedAt field in psql schema · Issu...
Is this suited for github? Yes, this is suited for github To Reproduce Setup better-auth with drizzle (provider=pg). Run npx @better-auth/cli generate. Current vs. Expected behavior Currently, it o...
GitHub
fix: schema onUpdate not working by himself65 · Pull Request #42...
Fixes: #4241 Summary by cubic Fixes onUpdate not being applied during updates. Fields like account.updatedAt now refresh correctly on password reset and password change. Bug Fixes Ensure onUpdat...

Did you find this page helpful?