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

[Introspection] "created_at timestamp with time zone not null default now()" doesn't work #1104

Closed
matthewmueller opened this issue Dec 6, 2019 · 7 comments · Fixed by prisma/prisma-engines#555
Assignees
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. topic: client types Types in Prisma Client topic: introspection
Milestone

Comments

@matthewmueller
Copy link
Contributor

Many postgres schemas have something like:

    CREATE TABLE note(
        id serial PRIMARY KEY,
        created_at TIMESTAMP WITH TIME ZONE not null DEFAULT now()
    );

or

    CREATE TABLE note(
        note_id serial PRIMARY KEY,
        created_at TIMESTAMP WITH TIME ZONE not null DEFAULT CURRENT_TIMESTAMP
    );

I've talked to @do4gr and he says we handle this wrong:

let default = col.get("column_default").and_then(|param_value| {
    param_value
        .to_string()
        .map(|x| x.replace("\'", "").replace("::text", ""))
});
@matthewmueller matthewmueller changed the title [Introspection] [Introspection] "created_at timestamp with time zone not null default now()" doesn't work Dec 6, 2019
@janpio janpio transferred this issue from prisma/prisma-engines Dec 10, 2019
@pantharshit00 pantharshit00 added bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. labels Dec 11, 2019
@janpio
Copy link
Member

janpio commented Dec 15, 2019

Can you provide an example what currently happens with tables like this @matthewmueller? Does it throw an error? Is the inferred model incorrect?

@pantharshit00
Copy link
Contributor

Right now we just don't have a default value for such fields:
image

@janpio janpio added this to the Preview 22 milestone Feb 4, 2020
@janpio
Copy link
Member

janpio commented Feb 6, 2020

Next steps:

  • Research what variants exist
  • Create a table that has some/all of them
  • Then see how this is introspected
  • If something is wrong, fix it

@janpio
Copy link
Member

janpio commented Feb 6, 2020

Related to #487

@danilofuchs
Copy link

danilofuchs commented Mar 15, 2020

Just in case another example is needed for testing, I created a simple schema in MySQL:

CREATE TABLE Todo (
  id INTEGER NOT NULL PRIMARY KEY AUTO_INCREMENT,
  description VARCHAR(255),
  completedAt DATETIME,
  createdAt DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updatedAt DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

The output schema.prisma:

model Todo {
  completedAt DateTime?
  createdAt   DateTime
  description String?
  id          Int       @default(autoincrement()) @id
  updatedAt   DateTime
}

@default decorators are not being set to createdAt and updatedAt fields.

@janpio
Copy link
Member

janpio commented Mar 17, 2020

This should be fixed in the current alpha version now.

Can you try and confirm this behaves as expected @matthewmueller and @danilofuchs? Thanks.

@danilofuchs
Copy link

Yes, indeed!
OLD:

model Todo {
  completedAt DateTime?
  createdAt   DateTime
  description String?
  id          Int       @default(autoincrement()) @id
  updatedAt   DateTime
}

NEW:

model Todo {
  completedAt DateTime?
  createdAt   DateTime  @default(now())
  description String
  id          Int       @default(autoincrement()) @id
  updatedAt   DateTime  @default(now())
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. topic: client types Types in Prisma Client topic: introspection
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants