What is the intended development workflow when applying migrations manually in Production?

[nkosi23]

Hello,

Thanks a lot for this wonderful library, i have decided to give it a go for my current project, the documentation is outstanding and the library is very polished.

The only obscure issue I've met was the one mentioned in this discussion, but as you guessed there it was due to a permission issue (the postgresql user who created the schema wasn't the one used in the connection string. Not sure why it didn't work though since we explicitly used CREATE SCHEMA myschema AUTHORIZATION theuser to create the schema but we probably forgot to do something during the process since we were configuring users & cie at the same time and the whole thing was made a bit in a hurry on our side).

Best Workflow to facilitate schema diffs between development and production?

What is the intended workflow to easily realize schema diffs between development and production when developers do not have direct access to the production database? (and therefore cannot do things such as pointing the db-patch tool to a production connection string).

Since the documentation suggests that objects auto-creation should only be used in development (and when looking at the DROP TABLE statements of the migration scripts one can understand why 😆 ) I am wondering what is the intended development workflow.

Actually, the reason I am asking this is that I've been adding features and entities on my development environment by letting MartenDb auto migrate everything. However when came the time to export the migration scripts to run them manually on the production database, MartenDB understandably returned a message saying that no migration script is needed since the current state of the database already matches the model in the development environment.

Since this was my first deployment to production, the easy solution was to delete the development database and run db-patch again. However, I fear that things won't be so easy when we will need to deploy version 1.1 to production and introduce a number of additional entities to the schema. Therefore, my question is how can we keep track of the production snapshot without sacrificing the development-time conveniences provided by MartenDB?

What about renaming entities

Still on the topic of migrations, when taking a look at the records saved in the database, I noticed that MartenDB saves fully qualified types including namespaces. What is the recommended way to move a type to a different namespace without affecting our ability to both save and deserialize entities already stored in the database? I've seen documentation on this related to the event store but nothing for basic documents and migration scripts.

Thank you