Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG]: timestamp with mode string is returned as Date object instead of string #806

Closed
noskovvkirill opened this issue Jun 22, 2023 · 12 comments · Fixed by #1659
Closed
Assignees
Labels
bug Something isn't working

Comments

@noskovvkirill
Copy link

noskovvkirill commented Jun 22, 2023

What version of drizzle-orm are you using?

0.27.0

What version of drizzle-kit are you using?

0.19.2

Describe the Bug

timestamps aren't being inferred as string
Table Schema that we use

export const itemTable = pgTable(
  'item',
  {
    id: bigint('id', { mode: 'number' }).primaryKey(),
    createdAt: timestamp('createdAt', {
      mode: 'string',
      precision: 6,
      withTimezone: true,
    }).notNull(),
    userId: uuid('userId')
      .references(() => userTable.id)
      .notNull(),
    customData: jsonb('customData').default(sql`'{}'::jsonb`),
    media3Id: bigint('media3Id', { mode: 'number' }).references(
      () => media3Table.id,
    ),
    newId: uuid('newId'),
    blockId: bigint('blockId', { mode: 'number' }).references(
      () => blockTable.id,
    ),
    parentItemId: bigint('parentItemId', { mode: 'number' }),
  },
  (item) => {
    return {
      parentReference: foreignKey({
        columns: [item.parentItemId],
        foreignColumns: [item.id],
      }),
      // indexes
      newIdIndex: uniqueIndex('idx_item_newid').on(item.newId),
    };
  },
);

Query

  const result = await db
        .select({
          item: {
            id: itemTable.id,
            createdAt: itemTable.createdAt,
            customData: itemTable.customData,
            newId: itemTable.newId,
            parentItemId: itemTable.parentItemId,
          },
          user: {
            id: userTable.id,
            username: userTable.username,
          },
          media3: {
            ...media3Table,
          },
          block: {
            ...blockTable,
          },
        })
        .from(itemTable)
        .where(eq(itemTable.id, input.id))
        .leftJoin(userTable, eq(userTable.id, itemTable.userId))
        .leftJoin(media3Table, eq(media3Table.id, itemTable.media3Id))
        .leftJoin(blockTable, eq(blockTable.id, itemTable.blockId))
        .limit(1);

Returns createdAt as a date object instead of string.

Expected behavior

Returns createdAt as string

Environment & setup

Vercel / Serverless function

@noskovvkirill noskovvkirill added the bug Something isn't working label Jun 22, 2023
@frostzt
Copy link

frostzt commented Jun 29, 2023

Hey @noskovvkirill new here wanted to start contributing, so wanted to pick this up! Also it would be fine if I asked for a little guidance if I ever get stuck? 😅

@noskovvkirill
Copy link
Author

@frostzt sure! let me know how I can help

@bestickley
Copy link

@noskovvkirill, I've run into this issue too. Could you clarify the title and change it to: "[BUG]: timestamp with mode string is returned as Date object instead of string"? The current title makes it seem like it's only a TS issue. This is a runtime issue though.

@noskovvkirill noskovvkirill changed the title [BUG]: timestamp is inferred as date instead of string [BUG]: timestamp with mode string is returned as Date object instead of string Jul 6, 2023
@noskovvkirill
Copy link
Author

noskovvkirill commented Jul 6, 2023

@noskovvkirill, I've run into this issue too. Could you clarify the title and change it to: "[BUG]: timestamp with mode string is returned as Date object instead of string"? The current title makes it seem like it's only a TS issue. This is a runtime issue though.

@bestickley good suggestion! I did that!

@pablomikel
Copy link

I'm actually seeing the opposite of this!

created_at: timestamp('created_at', { mode: 'date' })
    .notNull(),

^ this is returning an ISO string instead of a date object which doesn't match the expected Date type

I'm wondering if this has something to do with the Planetscale serverless driver...

@bestickley
Copy link

@frostzt, I think the fix needs to be made somewhere in here if you have time to take a look.

@bestickley
Copy link

bestickley commented Jul 19, 2023

My temporary workaround is to use the connection library (postgre.js for me) to transform the dates. See example below of what I'm adding to my Options.

transform: {
    value(value) {
      if (value instanceof Date) {
        return value.toISOString();
      } else {
        return value;
      }
    },
  },

@AndriiSherman AndriiSherman self-assigned this Jul 21, 2023
@stunaz
Copy link

stunaz commented Aug 31, 2023

I have the exact same bug....

@patrikengborg
Copy link

I have the same problem as well. The workaround from @bestickley is working, but a fix for this would be nice.

@K-Mistele
Copy link

I ran into this same issue - timestamp types with {mode: 'string'}are returned as Date objects. It's inferred as a string by TypeScript, but it's clearly a Date at runtime. This gives me issues when trying to return an object from the schema via getServerSideProps in Next.js, since Dates are not JSON-serializable (a string would be though) - I have to delete the date property from the object before returning it.

@Angelelz Angelelz self-assigned this Dec 12, 2023
@AndriiSherman
Copy link
Member

Should be fixed in drizzle-orm@beta. I would appreciate some feedback to confirm whether this issue has been resolved in this tag.

I plan to release it in version 0.30.0 tomorrow or within the next few days; I simply aim to address this substantial set of issues we're encountering. I'll be duplicating this message across all similar issues we're facing.

@AndriiSherman
Copy link
Member

Fixed in drizzle-orm@0.30.0

Please check release notes for more info

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
9 participants