wip: db scaffolding #4
Conversation
todo: create migrations
| model AppRule { | ||
| id String @id @unique @default(cuid()) | ||
| name String | ||
| value String | ||
| editable Boolean | ||
| validationValue String | ||
| app App @relation(fields: [appId], references: [id]) | ||
| appId String | ||
| appRuleType AppRuleType @relation(fields: [appRuleTypeId], references: [id]) | ||
| appRuleTypeId String | ||
| } | ||
|
|
||
| model AppRuleType { | ||
| id String @id @unique @default(cuid()) | ||
| validationType ValidationType | ||
| oneOrMany OneOrMany | ||
| appRules AppRule[] | ||
| } | ||
|
|
||
| enum ValidationType { | ||
| list | ||
| regex | ||
| } | ||
|
|
||
| enum OneOrMany { | ||
| one | ||
| many | ||
| } |
There was a problem hiding this comment.
I think we need to talk about this more. My goal was to separate this logically from the domain logic so there is a more clear handoff between the frontend and the gateway. This is where we went off track in our meeting, so I understand why our handle on this different.
| model User { | ||
| id String @id @default(cuid()) | ||
| email String @unique | ||
| name String? | ||
| id String @id @unique @default(cuid()) | ||
| org Org @relation(fields: [orgId], references: [id]) | ||
| orgId String | ||
| apps App[] @relation("UserApps") | ||
| } |
There was a problem hiding this comment.
I think we got off User too soon, since this is the first thing we'll need, we should model how we handle authentication in the database. Do we add eth_address here? Or do we link to an authentication interface which handles the implementation?
web-portal/.DS_Store
Outdated
There was a problem hiding this comment.
Can we avoid checking in OS specific files? Add to gitignore perhaps.
|
@plor ready for review from today's discussion; added [x] in comments at bottom |
|
I don't know if the changes made it in. Can you double check? Also, would it make sense to separate this from the web-portal and put it in a service layer? |
|
I did an oopsie; check now; also yeah will migrate Prisma to different path tomorrow |
web-portal/.DS_Store
Outdated
There was a problem hiding this comment.
Can you remove this from commit?
| paymentLedger PaymentLedger? | ||
| relayLedger RelayLedger? |
There was a problem hiding this comment.
I still think this is confusing, I'm curious how this looks in SQL form.
| tenantId String @unique | ||
| referenceId String | ||
| amount Int | ||
| chainId String |
There was a problem hiding this comment.
This will be important to tie to chain weight, I wonder if it needs to be generalized if there are other things we want to weight.
There was a problem hiding this comment.
to my understanding, based on what we discussed that would be a business logic (i.e. how to come to a chain weight); I would want to keep that separate
There was a problem hiding this comment.
Ok, I'll have to think about this, if we don't have the weight here we might obscure the logic.
| referenceId String | ||
| amount Int | ||
| chainId String | ||
| keyId String // fed from redis(redis-pg sync service // tbd |
There was a problem hiding this comment.
Just for reference, this might be necessary to have as a reference to the id on the key table so we have consistancy (a string here that doesn't match a row in the key table would result in brokenness).
|
Still wondering if we want a separate service layer from the portal backend, I don't know what the best way to logically separate this stuff is. |
There was a problem hiding this comment.
Just a couple nitpicks. Also, I think the naming on "services/postgres" isn't quite right. My point was more to push the tenant stuff to a service separate from the portal. So this would be something like a core-account service which would include the postgres and the api to serve postgres. I don't know if it makes sense to have postgres live in a project of its own.
web-portal/.DS_Store
Outdated
There was a problem hiding this comment.
I'm going to complain about this until it is gone
There was a problem hiding this comment.
hopefully in next commit; as I didn't see it was in a sub directory
services/postgres/schema.prisma
Outdated
| updatedAt DateTime | ||
| } | ||
|
|
||
| model Key { |
There was a problem hiding this comment.
I'm thinking "Key" might be too generic here, ApiKey or TenantAuthKey might be more descriptive.
There was a problem hiding this comment.
TenantAuthKey sounds best to me
|
|
||
| -- CreateTable | ||
| CREATE TABLE "Org" ( | ||
| "id" TEXT NOT NULL, |
There was a problem hiding this comment.
This might be nitpicky, but is it best to use text for these type of short string fields? I know I used to do VARCHAR(32) or something in the past. Does "text" not have any performance hit? I know this is generated, but I assume you can give prisma a hint.
todo: create migrations