I create a database via rake task successfully. But I have a problem while migrating my migration files for models. I always get the following problem related to postgres.
Related
I'm trying to add tables via my existing migrations so I can work on this locally on another machine.
I'm running the dotnet ef database update command in the terminal, but it doesn't create any of the tables - it only gets as far as:
Build started...
Build succeeded.
info: Microsoft.EntityFrameworkCore.Infrastructure[10403]
Entity Framework Core 6.0.7 initialized 'PingContext' using provider 'Microsoft.EntityFrameworkCore.SqlServer:6.0.7' with options: None
and that's the end of the command. It doesn't create the tables at all.
Any ideas?
There are several ways to upgrade from V8 what I read on several fora.
One of the methods is do exports of "main tables"
Which tables? And it only works good with smaller DB's.
And how big is big ? I have only Accounting , CRM, and Website modules on my Odoo 8 and I am self employed, not an enterprise.
I know that you can easily upgrade from 8 - > 10 .
If I use the OpenUpgrade software, does it make a new DB which can then be used with a new instance of Odoo with V12? Or does it migrate the complete instance db + software?
If I downgrade modules in V10, will the upgrade to V12 be easy. Or are there special tables written in the DB who can block the migration from V10 -> V12 ?
Migrations are tricky. The basic process will be:
Make a copy of your database and ship it to a separate environment
Run OpenUpgrade V9.0 with the --upgrade=all flag on the database
If you come across any errors, handle them individually by looking at the error and making the necessary changes to your modules
Once the upgrade completes, you can move forward and do the same for OpenUpgrade V10.0, V11.0 and V12.0
Copy your database back to production
When development is finished and TFS (VSTS) takes over. The build completes successfully and the artifact directory contains the published website via a build definition. The Release Manager is then triggered, and takes over and creates a website in an environment, the website files are copied to the environment and the website started. All good so far.
Missing the Database migration steps here...
Now someone starts the server and it fails because the database has not been migrated. How do we do that? The EF Tools were not copied to that environment, in fact we can't even run dotnet.exe because the core sdk has not been deployed onto that environment either. so even if we had the tools, we can't execute them.
In EF 6.x it was easy cause we could just copy migrate.exe as part of the artifacts, and run that on the environment after the files were copied. As I understand it, the EF Tools are now a DLL (ef.dll) that has to be run by dotnet.exe. Does this mean that all web servers now need Core SDK to perform migrations?
Other details about my project setup:
asp.net.core application being deployed onto a QA server for testing. This is not a dev box, does not have VS2015 installed, does not have Core SDK installed.
Update: EF.EXE is part of preview3 and 4.
This solves the requirement for "dotnet.exe" being installed. I can copy that into the artifacts drop like I used to with migrate.exe. Is this the proposed solution by the EF Team?
EF.EXE is part of preview3 and 4.
This solves the requirement for "dotnet.exe" being installed. I can copy that into the artifacts drop like I used to with migrate.exe. Is this the proposed solution by the EF Team?
Yes. Do this.
Also see issue #6313 where we want to make this experience a little easier on .NET Core.
In order to run .NET Core web application on your server, you need to install .NET Core SDK (currently 1.1) on your servers. Doing so will give you the dotnet command so that you can execute dotnet ef database update on your server environment to update the database to a specified migration.
I am using Spring-Boot v1.1.10.RELEASE for my spring based web application. My DB is Postgres & used Flyway for my DB migration.
The postgres sql script file is successfully executed by flyway-maven-plugin by the following maven command i.e. mvn compile flyway:migrate
But the same Postgres sql script file is throwing PSQLException: ERROR: COPY from stdin failed: The JDBC driver currently does not support COPY operations error when running through the Spring-Boot Application.java file.
NOTE: From spring-boot I am executing the script file on fresh DB i.e. at least there is no SCHEMA_VERSION table in DB.
Any inputs?
Thanks,
Baji
By default, Spring Boot 1.1 uses Flyway 3.0 which does not support COPY FROM STDIN. Support was added in 3.1. You can either upgrade to Spring Boot 1.2 (which uses Flyway 3.1 by default) or stick with Spring Boot 1.1 and try overriding the version of Flyway to 3.1.
I want to modify one DB which was developed with EF 4.1 (Code First). I upgraded the project into EF 4.3 and follow this steps:
http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx
Everything is going well, but when I want to test on current DB (EF 4.1 Code First), Update-Database raise this error:
Cannot scaffold the next migration because the target database was
created with a version of Code First earlier than EF 4.3 and does not
contain the migrations history table. To start using migrations
against this database, ensure the current model is compatible with the
target database and execute the migrations Update process. (In Visual
Studio you can use the Update-Database command from Package Manager
Console to execute the migrations Update process).
I was wondering how I can migrate an EF 4.1 (Code First) DB? Moreover that DB is live and has data and I cannot drop tables.
You need to create an empty migration and execute it prior to doing changes to your model. It will create the migration history table for you. After that you can use migrations for new changes. I wrote walkthrough article about this topic.
Run "Add-Migration InitialMigration -IgnoreChanges" before doing any changes to the model.. Make the required changes, then run "update-database"