I am using the console to generate migrations. In addition to the generated migrations, Hasura also writes a metadata.yaml file next to the migration folders:
- config.yaml
- migrations/
|-- 1583186121964_init/
|-- 1583363878794_another_migration/
|-- metadata.yaml <-- This file is generated along with new migrations,
but seems redundant
This seems to be the latest version of the metadata. However, this file does not seem necessary. I can wipe my Hasura state—both PostgresSQL and Hasura—remove this file, and upon hasura migrate apply everything is correctly restored based on the migrations alone. What is this file for? Just in case the migrations are bad?
Related
We've set our configuration file for doctrine migrations as the following:
doctrine_migrations:
migrations_paths:
'App\Migrations': "%kernel.project_dir%/src/Migrations"
Our migrations command all work, for example, doctrine:migrations:migrate works, doctrine:migrations:list will list all the migrations in our /src/Migrations folder. However, we cannot execute the doctrine:migrations:execute <versionNumber> command because it will give an error that it cannot find the migration file: "Migration class "20220329211652" was not found?"
Does doctrine:migrations:execute not work for custom migration paths configuration? When placing these migrations back in the default folder, it works.
It worked by using a fully qualified class name like:
bin/console doctrine:migrations:execute "App\Migrations\Version20220329211652"
Flyway supports environment variables in config files.
Is there a way to make Flyway load these variables from a file, similarly to what Docker and Node.js with dotenv do?
The content of the .env file is for example:
DB_URL=jdbc:postgresql://localhost:5432/db_name
And flyway.conf:
flyway.url=${DB_URL}
If you are using flyway-maven-plugin, you have 3 ways currently:
Defining flyway properties in POM.xml
eg.
<properties>
<flyway.url>jdbc:h2:mem:public;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE;MODE=MySQL;INIT=CREATE SCHEMA IF NOT EXISTS "public";</flyway.url>
<flyway.user>root</flyway.user>
<flyway.password></flyway.password>
</properties>
Defining your flyway properties in some .env or a .conf file.
mvn -Dflyway.configFiles=src/main/resources/some-env-file.env flyway:migrate
Contents of some-env-file.env:
flyway.url=jdbc:h2:mem:public;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE;MODE=MySQL;INIT=CREATE SCHEMA IF NOT EXISTS "public";
flyway.user=root
flyway.password=
Injecting the environment variables directly during maven goal execution:
mvn -Dflyway.url="jdbc:h2:mem:public;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE;MODE=MySQL;INIT=CREATE SCHEMA IF NOT EXISTS public;" -Dflyway.user=root -Dflyway.password=root flyway:migrate
But if you want to load properties from some file using properties-maven-plugin and make them available as enviroment variables, to be used by your flyway-maven-plugin , then unfortunately that is not working.
Here is the github issue tracking this.
How I can avoid creating folders like Controller, Entity and so on inside of src directory when I'm running composer install as I'm using different folder structure in my application and it's annoying to delete that folders each time I run composer install by the first time on some machine
These folders are created by different flex recipes ONCE.
Example for symfony/framework-bundle:
https://github.com/symfony/recipes/blob/master/symfony/framework-bundle/4.2/manifest.json#L8
After successful installation these changes are tracked into symfony.lock file.
Do you have that file? It needs to be added to VCS like composer.json/composer.lock
Then delete the unneeded folders from filesystem. They should not be created again.
Source:
https://github.com/symfony/flex/issues/419
I've noticed this recently, from a clean install of Symfony2 and removed AcmeDemoBundle (from the AppKernel, routing_dev.yml etc.). I generate the bundle and noticed that the Target directory for the bundle has changed and every time I create a new bundle I have to manually put in the proper path to it. Seems to be a problem with the latest release of Symfony2.
Changed Target directory line during bundle creation:
Target directory [/var/www/html/Project/app/cache/dev/../src]:
The path that it use to point was:
Target directory [/var/www/html/Project/src]:
I am at a loss for what changed as I installed a clean build and did not alter any settings.
When I installed Symfony2 I used the following: (which is the same way I've used previously)
composer create-project symfony/framework-standard-edition Project #stable
php app/console generate:bundle (see last line)
Welcome to the Symfony2 bundle generator
Your application code must be written in bundles. This command helps
you generate them easily.
Each bundle is hosted under a namespace (like Acme/Bundle/BlogBundle).
The namespace should begin with a "vendor" name like your company name, your
project name, or your client name, followed by one or more optional category
sub-namespaces, and it should end with the bundle name itself
(which must have Bundle as a suffix).
See http://symfony.com/doc/current/cookbook/bundles/best_practices.html#index-1 for more
details on bundle naming conventions.
Use / instead of \ for the namespace delimiter to avoid any problem.
Bundle namespace: Foo/FooBundle
In your code, a bundle is often referenced by its name. It can be the
concatenation of all namespace parts but it's really up to you to come
up with a unique name (a good practice is to start with the vendor name).
Based on the namespace, we suggest FooFooBundle.
Bundle name [FooFooBundle]:
The bundle can be generated anywhere. The suggested default directory uses
the standard conventions.
Target directory [/var/www/html/Project/app/cache/dev/../src]:
Fixed by updating composer:
composer self-update
Then creating a new project.
I have a Java Maven project. I'm using liquibase to update DB.
Locally, to update my db, I just run in command line:
mvn liquibase:update
In production environment, I don't have Maven installed.
What I need to achieve is through console, execute a command to run the liquibase scripts in a specific classpath.
Any ideas?
Edit:
Ok.I'm trying to follow this approach. I put in a folder the following items:
liquibase jar
The war containing my application and the liquibase changesets
liquibase.properties: It contains the following:
url=jdbc:jtds:sqlserver://xxxxxxxx:xxxx/xxxxx
username=xxx
password=xxxxx
classpath=war_file.war
changeLogFile=WEB-INF/classes/sql/projectName/liquibase/liquibase.xml
Then, in a console, I execute:
java -jar liquibase-core-3.0.5.jar update
It works! It finds my liquibase.xml file and starts the liquibase update.
BUT, when it refers to liquibase.xml that are inside another jar file included in the lib, it fails, because I included it in the liquibase.xml as:
<include file="../other_module/src/main/resources/sql/projectName/liquibase/liquibase.xml" />
How can I add this "include" without doing "src/main/resources" and make it find this xml?
Running the updateSQL goal on your Dev machine:
mvn liquibase:updateSQL
You can generate a migration script:
└── target
└── liquibase
└── migrate.sql
This is one of my favourite features of liquibase. Sometimes clients insist that all database schema changes must be performed manually by their staff.
Another option is to build an auto-upgrade capability into your application. See the servlet listener