Scaffold should not generate autogenerated fields

[aggmoulik]

Fix #3682

While creating the smart way of filtering out autogenerated fields, I found there are certain functions that are used with the default function in Prisma schema that is autogenerated, and obviously we should not generate those fields as well.

Primsa Default Function

Signed-off-by: Moulik Aggarwal qwertymoulik@gmail.com

[thedavidprice]

Ah, good catch @aggmoulik

Ping'ing @cannikin for review.

Thanks!

[cannikin]

Hmm, I'm not sure we always want to exclude all of these fields: just because the field is assigned a default value in the database doesn't mean you'll never provide a value to those fields. Just that if you do leave it NULL then it should automatically be given a value. For example, you may have a system that automatically posts to Twitter. There is a field named sendAt that you can customize if you want, for example you want to send a message an hour from now. But if you leave it blank, it should send right away (because the database will default to now()).

I could see something similar for cuid and uuid: they would act as unique identifiers for a record (say the slug for a blog post) unless you assign a unique identifier yourself.

Some folks may even set their own id value and not always rely on the database to generate one for them. We've kind of developed a standard in Redwood: every table should have an id column that is autogenerated, and optionally createdAt and updatedAt columns that are managed by the database (createdAt) and Prisma (updatedAt). (These are borrowed from Ruby on Rails). I feel like anything else should be fair game and should show in a form.

[aggmoulik]

Hey @cannikin, I understand your concerns here. I will remove the now(), cuid() and uuid() but I think we should exclude the following then:

  id Int @id @default(autoincrement()) // Already excluded in redwood
  uuid String @default(uuid()) // Will remove 
  cuid String @default(cuid()) // Will remove 
  autoincrementNotID Int @default(autoincrement()) // This case is not handled
  dbGeneratedField String @default(dbgenerated()) // this should be also excluded

I have tried to make it modular so that any change like this is automatically handled just by removing from constants.

[cannikin]

I don't think we should exclude fields marked as dbgenerated(): it only gets a default value if you don't specify one. It's just that the default value is managed by the database because Prisma doesn't understand what the value is. Prisma gives an example in their docs of the database populating the field with a random value. But maybe I do want to give it a value sometimes, so it would need to be in a generated scaffold.

[cannikin]

Howdy @aggmoulik hope you had a good holiday!

What did you think about my last comment?

[aggmoulik]

Howdy @aggmoulik hope you had a good holiday!

What did you think about my last comment?

Hello @cannikin Sorry for the late reply, as was stuck in personal problems. Will fix the PR after looking at your comments.

[aggmoulik]

@cannikin Updated the PR after your review.

[cannikin]

Thanks! Are there any tests that can be updated to show that these fields are no longer generated?

[cannikin]

Hi @aggmoulik did you see my previous comment? This PR looks good but I'd love to get a test or two in there that confirms it's behaving as expected!

[aggmoulik]

@cannikin Ok I will add tests for the same.

[netlify]

✅ Deploy Preview for redwoodjs-docs canceled.

Name	Link
🔨 Latest commit	9544743
🔍 Latest deploy log	https://app.netlify.com/sites/redwoodjs-docs/deploys/626055f90ab0c800085e63cb

[jtoar]

Hey @aggmoulik, no worries if not, but still interested in this one? If not we'll get it to the finish line! Just wanted to give you the chance since you worked so hard on it 🦾

[cannikin]

Thanks for the work on this @aggmoulik, you get all the credit!