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

Refactor prisma further #1891

Closed
wants to merge 2 commits into from
Closed

Refactor prisma further #1891

wants to merge 2 commits into from

Conversation

haworku
Copy link
Contributor

@haworku haworku commented Aug 25, 2023

Summary

Two proposed changes to new rates refactor db that have come up via Slack conversations and in person pairing.

  1. Supporting documents fields by using named relation, rather than standalone tables
  2. Add optional display_seq field.

Copy link
Contributor

@macrael macrael left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with this change. Having a single documents table seems like a win. I put in some notes.

supportingDocumentRevisionID String
contractDocumentContractRevision ContractRevisionTable? @relation(name: "ContractDocumentOnContractRevision", fields: [contractDocumentRevisionID], references: [id])
supportingDocumentContractRevision ContractRevisionTable? @relation(name: "SupportingDocumentOnContractRevision", fields: [supportingDocumentRevisionID], references: [id])
display_seq Int?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems a bit dodgy to have this be optional, when would we not want to set it? I think all of these things need to have a visual order every time

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@macrael The reason i didn't set this is we haven't discussed when and how it gets set. I was just adding it in to be used in the future since we discussed it in slack. Is it set in handlers I'm guessing - so on create or update prisma actions? And then we start to orderBy that in the queries? Let me know if that's right -- I will implement!

sha256 String
contractDocumentRevisionID String
supportingDocumentRevisionID String
contractDocumentContractRevision ContractRevisionTable? @relation(name: "ContractDocumentOnContractRevision", fields: [contractDocumentRevisionID], references: [id])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're going to do it this way, why not have a single documents table?

The reason I suggested we have 4 different tables here was that then the primary key could be required in the database, ensuring that we don't accidentally orphan a document at some point. But I don't think that's that big a deal, it would be nice if we could add a db constraint that made sure that one of the four primary keys were set so you can't make a document that doesn't belong to anything.

Copy link
Contributor Author

@haworku haworku Aug 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@macrael Gotcha, I am understanding you now. I might be missing something about how relations work let me know. I will keep looking around for a way to implement that type of constraint at the db layer.

@@ -110,32 +109,38 @@ const createRateRevision = (
supportingDocuments: [
{
id: uuidv4(),
rateRevisionID: 'rateRevisionID',
rateDocumentRevisionID: 'rateDocRevisionID',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't a document only ever have one parent ID?

Copy link
Contributor Author

@haworku haworku Aug 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an artifact of having the named relationship. Here are the docs. What do you think of this? Let me know your thoughts.

@haworku
Copy link
Contributor Author

haworku commented Aug 29, 2023

Closing this branch since I have changes in flights that will rework these migrations based on feedback - need to start a fresh branch.

@haworku haworku closed this Aug 29, 2023
@haworku haworku deleted the refactor-prisma-further branch October 11, 2023 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants