fluentmigrator
fluentmigrator copied to clipboard
fluentmigrator
Support for disconnected scripting?
Hi,
I have a very common use case in enterprise environments. My use case is that I have access to dev/test databases but not a prod database. So, I can run fluentmigrator against my development and test environments.
But when it comes to deployment I don't have access to my prod database. I haven't yet seen a way to create a script against a database that I don't have access to (while disconnected).
The work around I have been doing so far is to create a script against a dev database, make changes to it by hand, and then run it in prod. I would prefer not to manually edit scripts. It introduces the possibility of human error into my deployment process.
Ideally I think I would need to be able to specify the starting version (taking away the need for a VersionInfo table in an available database), and then just generate the script. I don't see any reason why this shouldn't work. It shouldn't fail because it can't connect.
I would also like to provide a start and end version [@jzabroski edit: This is now tracked in #1033]. So I could generate a script for example from version 5 to version 10. The need for this would be to generate incremental release scripts. Release two, three, etc.
Is this possible? It would be really helpful if it were.
How about this:
- Ask your DBA to create a readonly account for you in your prod database.
- Using that account in your connection string, run the migrator using the
--previewoption. - This should generate a sql script, against the production database, with no risk of modifying the production schema.
Would that work for you?
Peter, I doubt that will work due to issue #706.
On Fri, Mar 18, 2016 at 1:30 AM, Peter Kneale [email protected] wrote:
How about this:
- Ask your DBA to create a readonly account for you in your prod database.
- Using that account in your connection string, run the migrator using the --previewoption.
- This should generate a sql script, against the production database, with no risk of modifying the production schema. See if that works? You could even test it against your dev database using your own readonly credentials.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/schambers/fluentmigrator/issues/708#issuecomment-198227013
I agree that Peter's suggestion is a technical solution and will work in some situations, but there are also people/process challenges, particularly in enterprise environments.
In my organization, for example, there are numerous processes and individuals who can make getting production access impractical or even impossible. SOX compliance, access to sensitive data, segregation of duties are some of these processes which impede access to production data. There are even managers who will veto such requests on principle. I can write a script, so why would I require access to production data? I don't think, "Well, I have this tool that I like..." will do much to convince them.
In my case, I have already been using Fluent Migrator on a couple of projects. Now that these projects are going to production, it is getting tricky. I may have to remove it and go back to manual sql script writing if Fluent Migrator can't support disconnected scripting.
From the outside looking in, I would think it should be a fairly simple design change. Add a few additional parameters, providing from and to migration numbers so that a direct database connection is unnecessary.
Supporting disconnected scripting would add a great deal of flexibility and make this tool extremely useful. If it supported that, I would use it on every project and recommend it to all of my friends who work in conservative corporate environments. :)
This is a big issue, and not an easy one to get fixed :s
Although we have something in place that is almost working, it has deep connections to The fact that we have from v0.? Conditional support. For instance we can say to drop a table only if a table exist, which would not work in the case where you have no access to the db you are targeting.
I never got why people put this in the first place, for instance in the above case this would mean that for instance in a production environment the table could have already been dropped before. I really hope this never happens in reality because it means you have no control over the the target db !
This is one of the reasons, from when I originally joined this project. I voted against any pr further extending the conditional scripting. IMHO you use fluentmigrator because you wanna have total control of the schema, not just sometimes
No, not yet. FluentMigrator is built around the concept of migrations working on a connected database. The support for offline SQL generation seems to be an afterthought. It's definitely something that we have to take into account for a post-2.0 release.
Tom Marien notes:
Although we have something in place that would allow for disconnected scripting, it has deep connections to the fact that we have Conditional support. For instance we can say to drop a table only if a table exist, which would not work in the case where you have no access to the db you are targeting.
I would note that the issue is that the Conditional support isn't output as part of the script. This was raised recently. It also complicates generating a rollback script.
@ktodyruik notes:
I haven't yet seen a way to create a script against a database that I don't have access to (while disconnected).
Basically, you want to mock the version info table row data source? This should be covered under #978 , as it would also make the changes easier to test.
I would also like to provide a start and end version. So I could generate a script for example from version 5 to version 10. The need for this would be to generate incremental release scripts. Release two, three, etc.
This is now tracked in #1033. I think this should be a 4.0 feature, as it would change how the command line tool works.
