Hey alll.... not sure if we've got a weird requirement here....... We are wanting to use Prisma to interface with our database... we've used introspect to generate our schema, and we can deploy that and that works.... However.... the database structure may be updated somewhere else, and deployed separately... meaning that any future deployments of our database interface would possibly break.. I assuming this is where migrate comes in, and we need to be using migrate for updating our database structure now?

Ideally you would use migrate to handle changes to the database, however you can still manage without it. If your database is migrated externally, you could still introspect it and rebuild the application that uses Prisma. I would recommend an either/or approach and not try to partially do migrations with prisma and also migrations externally

yeah, I thought about the repeated introspect method, but then wondered how would I be able to tell if changes have been made that would possibly go missed during testing....

an introspect and parsing of a git diff could be one way, there is also the --print flag that prints the output of the schema but not a diff