How to deal with the introspected names, when using our own migrations?

[JMitnik]

Hi good folks,

I have had this pop up a number of times but liked to formalize it a bit better.

We recently made the jump from prisma 1 to prisma 2 as well

Considering the Migrate API is still experimental, we had been attempting to try to model our data in a 'table-first' way, using migrations from knex. One of the major pain-points we experienced when going about the bring your own migrations is in the fields we get generated for our expected data-types.

As an example, what one of our datamodels looks like before we edited it:

model QuestionNode {
  id                                      String           @id
  isLeaf                                  Boolean
  isRoot                                  Boolean
  title                                   String
  type                                    String
  
  // What do these relations refer to?
  Edge_Edge_childNodeToQuestionNode       Edge[]           @relation("Edge_childNodeToQuestionNode")
  Edge_Edge_parentNodeToQuestionNode      Edge[]           @relation("Edge_parentNodeToQuestionNode")
  NodeEntry                               NodeEntry[]
  Edge_EdgeChildrenRelation               Edge[]           @relation("EdgeChildrenRelation", references: [id])
  QuestionNode_A                          QuestionNode[]   @relation("QNodeToOverrideLeaf", references: [id])
  QuestionNode_B                          QuestionNode[]   @relation("QNodeToOverrideLeaf", references: [id])
  Questionnaire_QuestionnaireRootQuestion Questionnaire[]  @relation("QuestionnaireRootQuestion", references: [id])
  Questionnaire_QuestionnaireToLeafNodes  Questionnaire[]  @relation("QuestionnaireToLeafNodes", references: [id])
  Questionnaire_QuestionnaireToQuestions  Questionnaire[]  @relation("QuestionnaireToQuestions", references: [id])
  QuestionOption                          QuestionOption[] @relation("QuestionNodeOptions", references: [id])
}

What the datamodel looks like after we adjusted and made it more readable:

model QuestionNode {
  id                                      String           @default(cuid()) @id
  isLeaf                                  Boolean          @default(false)
  isRoot                                  Boolean          @default(false)
  title                                   String
  type                                    String

  // More readable and usable
  overrideLeafId                          String           @map("overrideLeaf")
  overrideLeaf                            QuestionNode     @relation("QNodeToOverrideLeaf", fields: [id], references: [id])
  isOverrideLeafOf                        QuestionNode[]   @relation("QNodeToOverrideLeaf", references: [id])
  children                                Edge[]           @relation("EdgeChildrenRelation", references: [id])
  options                                 QuestionOption[] @relation("QuestionNodeOptions", references: [id])

  isChildNodeOf                           Edge[]           @relation("Edge_childNodeToQuestionNode")
  isParentNodeOf                          Edge[]           @relation("Edge_parentNodeToQuestionNode")
  NodeEntry                               NodeEntry[]
  rootQuestionBelongsTo                   Questionnaire[]   @relation("QuestionnaireRootQuestion", references: [id])
  leafBelongsTo                           Questionnaire   @relation("QuestionnaireToLeafNodes", fields: [id], references: [id])
  leafQuestionnaireId                     String?          @map("leafBelongsTo")
  questionBelongsTo                       Questionnaire    @relation("QuestionnaireToQuestions", fields: [id], references: [id])
  questionQuestionnaireId                 String?          @map("questionBelongsTo")
}

These schemas changed a bit in between in other factors, but I hope it can show what I mean. The original column-names from relations are rather verbose, and quite hard to read / use in the rest of the application (when a client is based on this in that sense).

We are aware that we can simply rename the relation fields, but what would happen when we make an edit to the database (using a new migration), is that we would lose these changes, which would introduce a buffer to our experience in editing our data model. As such, we feel like we are a bit stuck between a rock (hard-to-read introspected relations) and a hard place (an experimental API).

We do love the product, so we are considering jumping in the bed with prisma migrate instead, and hope the various changes to the API won't break our application or deployment too much.

Still, we would love some input from how people look at this issue. Thanks!

[ryands17]

Hey @JMitnik 👋
Yes is this an issue a lot of folks are facing due to the bring your own migrations strategy for now. The best way to approach this would be using a post instrospection script as stated here so you could then after prisma introspect run this script so that it maps the model fields correctly without manual intervention!

This would be the best approach until prisma migrate is stable.

[JMitnik]

Hey Ryan, thanks for answering! We will keep this in consideration, thanks :)!