how can I disable completly the migrations of EntityFramework? I mean, what are the best practies when you are almost ready to go live with your web app? I'm worried that some automatic script reset my DB :)
Many thanks,
davide
Migrations are normally used on the development database. For production I would suggest that you instead export an SQL script using the Update-Database -Script command which can then be run on your live database when you need to update it. It would be dangerous to have your development application pointing to a live DB and to run migrations directly.
Related
Ok, let's say
I changed Prisma schema and ran yarn prisma migrate dev and created a migration.
I noticed there was a typo in schema, so I fixed it
I forgot to run yarn prisma migrate dev again after fixing a typo, so no migration was created for this change.
And this mistake went to a pull request. And it will be merged if nobody notice this mistake.
And this point, how can CI detects there is a schema change but no migration for that?
Thanks.
I just decided to use Circle CI's no_output_timeout: 1m option on run. and just run yarn prisma migrate dev with postgres docker image on CI.
So, if there is no unsynced stuff between schema and migration, it will pass.
If not, the promft will wait for user's input to get new migration name, so Circle CI's timeout kicks in here and it will make it fail. So we're able to know there was a mistake.
It works pretty well.
I build a simple inventory management app. Now I would like to publish it as a single executable file (.exe) including the database and all dependencies. The purpose is to use it offline on another machine. I tried with deployment mode: ``Self-contained`` and file publish option as: ``produce single file``, ``Enable ReadyToRun compilation`` and ``Trim unused assemblies`` in visual studio. But that does not include database niter producing a single file.
Now in this case what should I do? Can anyone help me?
Regards,
Nazmul
You should create a migration file with command and run it on SQL, or use ci/cd to deploy it.
Pay attention to these links:
about Migration
about deployment
Well, I found a solution by myself. By using SQLite Database instate of MSSQL. Since my application is not a multiuser application that will not be an issue. But if you are thinking of a multiuser app you better not use SQLite. You can use it by installing the Microsoft.EntityFrameworkCore.Sqlite plugin.
if anyone finds a better solution let me know.
our team currently updates our production databases via the dacpacs/bacpacs since we do not have any client data. This will not be the case in the near future and I'm looking to change the process of only modifying the database via SQL scripts via build automation.
Is managing these SQL scripts in Team Foundation Server and executing them in the build do-able? And If so how have people approached this?
Thanks!
You should probably not be deploying DACPACs during the build process; it's more appropriate to push changes as part of a release/deployment workflow that occurs after a build.
That said, you can publish a DACPAC without dropping the database and recreating it; there are numerous options for controlling the database publishing behavior that can be set at the project level and overridden at the command line if necessary.
There are two main ways of managing SQL data base changes when deploying to production.
DACPAC
Sequential SQL Scripts
Both have there own issue and bonus when trying to deploy. If you control your entire DevOps pipeline then Dacpac is a good option. If you have to deal with corporate dba's then SQL scripts can also be done.
I got an application written in YII that from time to time will need version update. Currently, when we release a new update, we manually run a shell script to copy/overwrite the application code/source files from our git repo and set the appropriate permissions and other things, then at the end of the script, we run a YII command to run our database update. We have versioning on our database update. We also rollback changes to the database if one of the sql statements of a version fails. Now the issue occurs if a database update fails, and the application code/source is updated, then it will fail when it tries to access some table fields, table or views.
How to best handle an application update with versioning? Much like the way wordpress handles its update or better.
Would like to ask for suggestions to the rigth approach, it may include RPM, GIT or other info.
It would be good to have a detailed list of processes from you guys.
Thanks.
Database updates may include backups, and running multiple scripts, and
should be handled outside of rpm packaging. There are too many failure modes
for RPM scripting to handle flawlessly.
You can always package up the database schema update script in the package
and then check for the correct schema version when your application starts,
providing instructions (or a pointer to instructions) on how to upgrade the
database, and how to reinstall the last-known-good application, when the wrong
schema version is detected.
Boys and girls,
So, I have finished my Rails3 webapp and I am trying to deploy it. Am using Passenger, I have managed to configure it as to point to the rails app, that is fine.
Now, since in development i have made of course changes to the app and I want to deploy it with the data i have imported until now. I tried to "rake db:migrate RAILS_ENV=production, but the data are lost! Even the users I have created while developing are lost and need to create them again...
Isn't there any way to keep the data while moving from development to production environments?
Thank you very so much...
Previously I have used the yaml_db gem to do export from one environments db to another and it's worked great.
That said, running migrations shouldn't cause all your data to disappear. Is your db being destroyed and then re-created or is it actually emptying the tables? Also, how are you deploying the app to production - using capistrano? If so check that there are no unwanted extra tasks being run as part of the deployment