I am going to make a db migration file and migrate the file to database by using the a command.
But I can't find the command.
In Laravel we approach the goal by using this command.
php artisan make:migrate migration_client_table
Is there any similiar command that acts like the php artisan make:migrate command?
Coming from Laravel/Symfony background as well, I was asking this myself. Here are my findings:
Laminas uses laminad-db module for interactions with database. Documentation for this module however does not mention migrations at all.
Database and Models introduction to Laminas uses sql file to create a table and fill it with some original seed and does not mention altering tables at all.
Therefore I made assumption Laminas does not handle migrations at all.
Edit: According to this answer, we can use sqitch, doctrine/migrations or liquibase
Related
I use this boilerplate app to learn NestJs GITHUB LINK. The template is amazing but there was one thing that I can't fix migrations. When I try to add a new entity or use an existing one with npm run migrate:create Init migration was successful
Migration D:/src/database/migrations/1657796180301-init.ts
has been generated successfully.
but without any updating on the migration file or database. Only If I use synchronize: true and start the app the database was updated.
try to run migration:generate to generate new migrate file.
You have to run migration:run to apply migrations. This process is not done automatically because some migrations will cause you to loose data (dropping a column for example), so this gives you a chance to validate migration file before applying it.
I am trying to use the Keycloak docker image with a non-standard database (HANA-DB).
Modifying the configuration as described in the documentation worked fine and keycloak connects to the database. The remaining problem seems to be that the Liquibase migrations can not run because Liquibase does not know how to handle HANA-DB out of the box.
Of course, there is an extension library (https://mvnrepository.com/artifact/org.liquibase.ext/liquibase-hanadb/4.0.0) that adds this capability to Liquibase. Now my question: How do I get Keycloak's Liquibase to use this library?
I already tried:
Packaging the library into its own module and adding a dependency to it in Keycloak's Liquibase module
Adding the library as a second resource-root to Keycloak's Liquibase module
Both did not work, i.e. Liquibase is still not recognizing the "HDB" database.
What would be the correct way to do this?
I actually made it!
The way i achieved it is not perfekt, but keycloak 11.0.2 Docker Image is running.
Keycloak with Hana and Liquibase Migration to Hana DB is working and by now all tests for us have passed.
I'll just give you a short description what I did. And maybe write a little Blog Entry for that.
Basically you answer helped me at some point and you were on the right track.
What I did:
Creating another DB Vendor for JBoss CLI Bootstrap Scripting (https://medium.com/#victor.boaventura/keycloak-using-alternative-databases-e2b13576c457).
Hana DB Driver also needed a Global Module /subsystem=ee:write-attribute(name="global-modules",value=[{"name" => "jdk.net","slot" => "main"}, {"name" => "org.liquibase","slot" => "main"}]) (JBOSS CLI)
Keycloak did not autodiscover the correct Hibernate Dialect, so had to add that as well: /subsystem=keycloak-server/spi=connectionsJpa/provider=default/:write-attribute(name=properties,value={"dataSource" => "java:jboss/datasources/KeycloakDS","initializeEmpty" => "true","driverDialect" => "org.hibernate.dialect.HANAColumnStoreDialect","migrationStrategy" => "update","migrationExport" => expression "${jboss.home.dir}/keycloak-database-update.sql"})
Updated the Liquibase Module to Version 3.6.3 and added Liquibase Hana DB Adapter 3.9.0 (https://github.com/liquibase/liquibase-hanadb) as second resource root in same module. (Was kinda tricky to get the versions working) Also the Module needed another dependency on 'org.slf4j' to get the Logging to work.
At this Point I struggled with Liquibase Package Scanning and Keycloaks exclusion on 'liquibase.ext'. Thats why I had to add the SystemProp 'liquibase.scan.packages' (Thanks to you here :))
liquibase.scan.packages=org.keycloak.connections.jpa.updater.liquibase.lock,liquibase.change,liquibase.changelog,liquibase.database,liquibase.parser.core.xml,liquibase.precondition,liquibase.datatype,liquibase.serializer.core.xml,liquibase.sqlgenerator,liquibase.executor,liquibase.snapshot,liquibase.logging,liquibase.diff,liquibase.structure,liquibase.structurecompare,liquibase.lockservice,liquibase.sdk.database,liquibase.ext
After that Keycloak recognized Hana DB for Liquibase and the Migration started. I was super happy, but one Problem solved the next comes up...
2 of the liquibase changelogs were not working with Hana DB due to some SQL specifics. Thats why I created two patches and applied them to the keycloak-model-jpa module. Basically they already handled special cases (that failed) for oracle, so I just added 'hana' to every preCondition, where 'oracle' was mentioned and it worked!
This is basically my solution. If you have any questions please feel free to ask them here or contact me.
It turns out, that adding the library as a second resource-root in Keycloaks's liquibase module is actually working. It does not get loaded because Keycloak removes liquibase.ext from the service loader used to find liquibase extensions.
This can be worked around by using the liquibase.scan.packages system property, though.
For all those trying to make Keycloak working with HANA:
Overriding the liquibase.scan.packages system property causes the library to be loaded
Now, a class (LoggingService) from liquibase that is referenced in the liquibase-hanadb library, can not be found because it was introduced in liquibase 3.6 and Keycloak comes with 3.5.5.
When hacking a more recent version of liquibase (3.6.0) into Keycloak's modules, for some reason a changeset only intended for DB2 is being run, causing errors. I suspect an incompatibility between Keycloak's changelogs and the updated liquibase version.
I gave up at this point.
Is it possible to automatically create migration files when using sequelize?
For example if I change my model, is there a way to automatically create a migration file that reflects those changes and run the migration to effect those changes in the database. Or do I have to manually create migration files myself?
I am using PostgreSQL.
There is a package for that
Sequelize-mig
its maintained and documented.
Install it with:
npm install sequelize-mig -g / yarn global add sequelize-mig
then use it like this
sequelize-mig migration:make -n <migration name>
and it will generate the migration file
I highly recommend Sequelize-mig, as referenced by MRVMV. I have 25 years of experience in creating my own ORM, and for my most recent project I decided to finally use an existing ORM. I chose Sequelize and as I got going with it, I was sorely disappointed that it does not have the ability to automatically genereate migration files by inspecting model files. This issue landed me here in this SO thread, and so I tried sequelize-mig. I read the docs and tried it out for about 4 hours and I find it to be working very well.
Using it, you can just create/modify your models .js files, then call "npx sequelize-mig migration:make --preview" to see what it will do. Carefully inspect all the preview code and make changes until you love the result. Then call "npx sequelize-mig migration:make -n <>" and it will populate the migration files. Carefully inspect those and when you love them, then use sequelize to migrate to your dev database by calling "npx sequelize-cli db:migrate" and that's it.
Next up, I will decide upon the best way for moving these migrations to production. But that decision doesn't have anything to do with sequelize-mig - it is the same decision you have to make for sequelize itself, just that now you get automatic generation of your migration files, thanks to sequelize-mig.
Highly recommend sequelize-mig!
Before anyone marks this as a duplicate, none of the questions similar to this addressed any of my concerns or answered any of my questions.
I am currently developing all the POCOs and data contexts in a library project, and running migrations from within this project. The database I'm updating is the development database.
What do I do if I want to create the current schema to a fresh, new database? I figure that all I have to do is to change the connection string in web.config and run Update-Database, correct?
While the live/production database is up and running, I want to add new columns and new tables to the schema, and test it out in development. So I switch back the connection string to the development database's connection string, and run Update-Database.
Going back and forth between two databases seems like I'll get conflicts between _MigrationHistory tables and the auto-generated migration scripts.
Is it safe to manually delete the _MigrationHistory tables in both databases, and/or delete the migration files in /Migrations (so I'll run Add-Migration again)? How do we manage this?
What do I do if I want to create the current schema to a fresh, new database?
- Yes, to create fresh database to the current migration level you simply modify the connection string to point to a database that does not yet exist and run update-database. It will run all the migrations in order.
As far as migrating to the Production database, I am running the update-database command with the -script switch to acquire the raw sql and then applying that script to the production database manually. This is helpful if you need to keep a record of sql commands run against the database as well. Additionally, you can generate the script explicitly from a specific migration to another specific migration via some of the other update-database switches.
Alternatively, you can create an Idempotent script that works from any migration by using the–SourceMigration $InitialDatabase switch and optionally specify an end migration with –TargetMigration
If you delete the _MigrationHistory tables you will have issues where the generated script will be trying to add columns that already exist and such.
You may find the following link helpful:
Microsoft Entity Framework Migrations
I would suggest having a separate trunk in your source code repository - one pointing to production and one to development to avoid risks of switching between the two in visual studio.
Me also had the same problem, even when using one and the same database - due to some merges in the repository, and the mix of automatic/manual migrations. For some reason the EF was not taking into account the target database, and calculating what scripts need to me executed, based on what is already in the database.
To fix this, I go to the [__MigrationHistory] table on the target database and get the latest migration name. This will help EF to determinate the state of the DB, and will execute just the scripts needed.
then the following script is run:
update-database -script -sourcemigration {latest migration name}
This creates update script that is specific to the target database (the connection string should be correct, as discussed in the other comments)
you can also use -force parameter if needed
this way you can update any database to latest version, no mater in what version you found it, if it has MigrationHistory table.
Hope this helps
My production and my developmental database went out of synch and it gave me endless problems. I solved it using a tool from Red-Gate to match up the databases. After using the tool, the databases were exactly the same but my migration was not working and I started to get odd errors i.e. trying to add tables/ columns that already existed etc. I solved that. I just deleted the migration folder on the local, recreated it, added the initial migration, updated the database and then matched the data of this migration file (local) to the one on the host (delete all the data in the migration file on the host, and add the same data that is on the local into the host). A more detailed explanation is at:
migration synch developmental and production databases
It looks like CodeFirst stops doing its homework when it doesn't have full control of the database (I suppose).
The scenario is a web site hosted on Arvixe.com (or I suppose any other shared hosting server), where I have to create databases only from their control panel (and NOT with Sql Server Management Studio, just to say...).
Once created an empty database, I register a connection in the web site, and I use it to generate database from poco objects like in:
add-migration m1 -targetdatabase myconnection
This generates correctly my FIRST migration, that I can apply without problems with
update-database -targetdatabase myconnection
The first concern, not too important, is that since the database is existing, it will NOT issue the Seed command, so I have to insert my first records by hand, but this is not a great problem.
Then I change my poco objects, and I need to update the database, but when I issue ANOTHER
add-migration m2 -targetdatabase myconnection
it gives the error:
System.Data.Entity.Migrations.MigrationsPendingException: Unable to generate an explicit migration because the following explicit migrations are pending: [201111081426466_m1]. Apply the pending explicit migrations before attempting to generate a new explicit migration.
This is really strange, since if I look at the database, I can see even the table __MigrationHistory, but then it looks like it cannot recognize it...
Anyone with the same problem, or some good tip to where investigate?
Thanks in advance,
Andrea Bioli
I had this problem. I was able to resolve it by providing a connectionString and a connectionProviderName parameter to both the Update-Database and the Add-Migration commands.
If you have many projects in your solution with multiple config files, Package Manager seems to be confused. In my case, I had one project selected as the default project for Package Manager Console, but it was pulling the connection string from the Visual Studio solution default start-up project instead.