Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Database type mismatch upgrading from 0.4.4 to 0.5.0 #53

Closed
gilzow opened this issue Nov 8, 2022 · 4 comments
Closed

Database type mismatch upgrading from 0.4.4 to 0.5.0 #53

gilzow opened this issue Nov 8, 2022 · 4 comments

Comments

@gilzow
Copy link
Collaborator

gilzow commented Nov 8, 2022

Just tried to upgrade from 0.4.4 of ddev-platformsh to 0.5.0.
In an existing project that already uses ddev, already had ddev-platformsh installed (0.4.4), and where ddev was not currently running, I ran

ddev get platformsh/ddev-platformsh 

ddev downloaded the tarball for 0.5.0, and then informed me:

Using existing PLATFORMSH_CLI_TOKEN.
 
Using existing PLATFORM_PROJECT from project config.yaml.
 
Using existing PLATFORM_ENVIRONMENT from project config.yaml.

It then showed:

could not process pre-install action '#ddev-nodisplay

followed by several lines of bash code. At the end it showed

: exit status 1, output=There is an existing database in this project that doesn't match the upstream database type.
 Please use 'ddev delete' to delete the existing database and retry, or try 'ddev debug migrate-database mariadb:10.4' to migrate the database.

but i cant tell if that is still part of the bash code, or if it is an actual message. The db in the upstream is:

db:
    type: mariadb:10.4

and the db info in .ddev/config.yaml is

database:
  type: mariadb
  version: "10.4"

so there shouldn't be a mismatch.

@gilzow
Copy link
Collaborator Author

gilzow commented Nov 8, 2022

❯ ddev version
 ITEM             VALUE                                   
 DDEV version     v1.21.3                                 
 architecture     amd64                                   
 db               drud/ddev-dbserver-mariadb-10.4:v1.21.3 
 dba              phpmyadmin:5                            
 ddev-ssh-agent   drud/ddev-ssh-agent:v1.21.3             
 docker           20.10.8                                 
 docker-compose   v2.10.2                                 
 docker-platform  docker-desktop                          
 mutagen          0.16.0                                  
 os               darwin                                  
 router           drud/ddev-router:v1.21.3                
 web              drud/ddev-webserver:v1.21.3  

@rfay
Copy link
Member

rfay commented Nov 9, 2022

: exit status 1, output=There is an existing database in this project that doesn't match the upstream database type.
Please use 'ddev delete' to delete the existing database and retry, or try 'ddev debug migrate-database mariadb:10.4' to migrate the database.

So you had an existing database that didn't match mariadb:10.4- My bet it was a mariadb:10.3 db, which used to be the default. You can find out the actual type of the database with ddev debug get-volume-db-version

The error message tells you several things you can do, but it doesn't tell you what the existing type is. I'd be interested in how you think it can be improved.

@rfay rfay changed the title issue encountered upgrading from 0.4.4 to 0.5.0 Database type mismatch upgrading from 0.4.4 to 0.5.0 Nov 9, 2022
@gilzow
Copy link
Collaborator Author

gilzow commented Nov 9, 2022

Mariadb is set to 10.4 in .platform/services.yaml and in .ddev.config.platformsh.yaml

❯ ddev debug get-volume-db-version
mariadb:10.4 

@rfay
Copy link
Member

rfay commented Dec 9, 2022

I expect this to be a standard problem, but think it's covered in

The debug technique is what you did, and if ddev debug get-volume-db-version and we have the same version in the .ddev/config.platformsh.yaml, then we'll have to chase.

I'm not sure what the situation was here, but let's chase it with ddev debug configyaml and ddev debug get-volume-db-version next time it happens. Closing in favor of #58

@rfay rfay closed this as completed Dec 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants