4 ms·

Thanks for sharing your thoughts. Daniel from the Prisma team here. regarding 1: Can you share more about schema generation problems? Are you using introspecti

by 2color 6y ago

Thanks for sharing your thoughts. Daniel from the Prisma team here. regarding 1: Can you share more about schema generation problems? Are you using introspection to create the Prisma schema? If so, we're actively working to improve this flow with "re-introspection": https://github.com/prisma/prisma/issues/2829 https://github.com/prisma/prisma/issues/2829 Regarding 3: Prisma supports transactions with nested writes and it's stable (https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/transactions#how-prisma-client-supports-transactions-today https://www.prisma.io/docs/reference/tools-and-interfaces/pr...). The new experimental transaction API pushes the idea of transactions further by combining multiple individual Prisma Client calls into a transaction. Long running transactions are indeed not supported. Long-running transactions require holding a stateful connection open between two components for an extended period of time which can be at odds with the way modern scalable systems are built. Perhaps you can share more what you/app developers mean by transaction?

dfee 6y ago
Hey dude! 1) schema-generation: uh, I can't find the video anymore! But basically (https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-migrate#typical-workflow https://www.prisma.io/docs/reference/tools-and-interfaces/pr...) when you re-generate your schema, FK relationships names would be reset, and you'd have to go back through and manually re-update them. (think user.favorite_book would be changed to user.book). Jeeze, I wish I could find the video for that. 3) perhaps I just don't have a good enough understanding of that system to think through it's pitfalls. You guys obviously understand which workflows you cover well through /that/ approach to transactions. Might be good to see which sorts of strategies (won't work). For example, what if I want to `flush` my changes, and `rollback` or use a `savepoint` elsewhere. It seems like everything is in the context of one call. Is that correct?
- 2color 6y ago
  1) Prisma supports two workflows depending on whether you already have an existing database (introspection) or using Prisma Migrate. It sounds based on your description like something that would happen in the introspection workflow which this "re-introspection" feature resolves by retaining name mapping of relation fields. 3) > For example, what if I want to `flush` my changes, and `rollback` or use a `savepoint` elsewhere. That's not possible. > It seems like everything is in the context of one call. Is that correct? Not exactly, as you can batch multiple calls into one transaction guaranteeing that either all get committed or none. (https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/transactions#the-transaction-api https://www.prisma.io/docs/reference/tools-and-interfaces/pr...)

by 2color 6y ago

dfee 6y ago

Hey dude! 1) schema-generation: uh, I can't find the video anymore! But basically (https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-migrate#typical-workflow https://www.prisma.io/docs/reference/tools-and-interfaces/pr...) when you re-generate your schema, FK relationships names would be reset, and you'd have to go back through and manually re-update them. (think user.favorite_book would be changed to user.book). Jeeze, I wish I could find the video for that. 3) perhaps I just don't have a good enough understanding of that system to think through it's pitfalls. You guys obviously understand which workflows you cover well through /that/ approach to transactions. Might be good to see which sorts of strategies (won't work). For example, what if I want to `flush` my changes, and `rollback` or use a `savepoint` elsewhere. It seems like everything is in the context of one call. Is that correct?

2color 6y ago
1) Prisma supports two workflows depending on whether you already have an existing database (introspection) or using Prisma Migrate. It sounds based on your description like something that would happen in the introspection workflow which this "re-introspection" feature resolves by retaining name mapping of relation fields. 3) > For example, what if I want to `flush` my changes, and `rollback` or use a `savepoint` elsewhere. That's not possible. > It seems like everything is in the context of one call. Is that correct? Not exactly, as you can batch multiple calls into one transaction guaranteeing that either all get committed or none. (https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/transactions#the-transaction-api https://www.prisma.io/docs/reference/tools-and-interfaces/pr...)