MrLeebo/prisma-ast

Doesn't extend existing model

niba opened this issue · 6 comments

niba commented

Hey.
I've been trying to modify my existing schema using your lib but it seems that my every change produces a new model entry even if the model already exists

This is my code

 const schemaBuilder = createPrismaSchemaBuilder(schemaAsString); // in schema there is TaskScript model

 schemaBuilder.model("TaskScript").field("createdAt2", "DateTime").attribute("default", [ { name: "now" }]);
 schemaBuilder.model("TaskScript").field("updatedAt2", "DateTime").attribute("updatedAt");

My output is

image

so in the output I have three definitions of the TaskScript model. Do you have any idea why this is hapenning?

Can you show the original TaskScript definition in your prisma schema? Also, please check if version 0.4.3 resolves it for you.

niba commented

There is an improvement with 0.4.3. Now the lib doesn't duplicate my models but it does duplicate fields inside models

image

I tested on different models and the result is the same so the body of TaskScript is not important here

@niba OK. I didn't originally intend for fields to have the same "Add or update" behavior that models get, but I agree it makes sense for them to do that too. Since with models it was an expected behavior that wasn't working, I published that fix as a patch, but since this is changing the expected behavior for fields, I've upgraded this update to a minor release (v0.5.0) and added an example about it to the README.

Note that attributes WON'T behave this way, and you will still see duplicate attributes if you call builder.attribute("foo") twice. Reason is that multiple instances of the same attribute is theoretically a valid use case.

niba commented

@MrLeebo okay, my bad. I thought that it supposed to work in that way

So is there a way to rewrite an existing field? My case is that I have schema generated from existing DB and all of createdAt and updatedAt DateTime fields have wrong attributes. I wanted to use your tool to write a script that replaces all attributes of createdAt and updatedAt. So basically change createdat DateTime? @db.Timestamptz(6) to createdat DateTime? @default(now())
My result right now is what you said: createdat DateTime? @db.Timestamptz(6) @default(now())
I would like to remove this @db.Timestamptz(6) attribute but dont know how.

I've added builder.removeField('fieldName') and builder.removeAttribute('attributeName') helpers to help with these kinds of edits, so you can change it by dropping and re-creating the field or attribute.

model TaskScript {
  createdAt DateTime? @db.Timestamptz(6)
}
builder
  .model('TaskScript')
  .field('createdAt')
  .removeAttribute('db.Timestamptz')
  .attribute('default', [{ name: 'now' }]);
model TaskScript {
  createdAt DateTime? @default(now())
}

But, it isn't exactly scalable to just keep adding new helpers for every interaction with the builder, so another thing you can do is programmatically access the underlying schema object that prisma-ast builds. This is a good way to make custom changes to the schema.

import { Field, Attribute } from '@mrleebo/prisma-ast'

builder
  .model('TaskScript')
  .field('createdAt')
  .then<Field>((field) => {
    const attribute: Attribute = {
      type: 'attribute',
      kind: 'field',
      name: 'default',
      args: [{ type: 'attributeArgument', value: 'now()' }],
    };
    field.attributes = [attribute];
})
model TaskScript {
  createdAt DateTime? @default(now())
}

It's a little bit more verbose, but it gives you more flexibility to write your own custom logic. You can chain .then() calls on fields, models, and other block-level elements like generators, datasources, and enums. And this is the same underlying object that the existing helpers manipulate.

niba commented

Really thank you for this awesome support.
I tried your new API and had some problems with removing my 'db.Timestamptz(6)' attribute. I dont know why but it didn't want to remove it. Maybe because of this argument (6)? You can try to test it again because someone can have this problem in the future.

The second approach was much better for me. I managed to do everything what I want and now I have full control over my fields. Thanks for that.

Happy new year 🎉!