I am working with merging master into a branch that was made some time ago. It created a Hasura migration and then several more were added in master.
There are now merge conflicts in metadata/tables.yaml. tables.yaml is generated and maintained by Hasura, correct?
Hasura won't start with the conflicted tables.yaml. I replaced it with one from hasura init and was able to remove the Docker images (docker-compose down -v) and recreate them (docker-compose up --build -d).
When I run hasura migrate status it shows all the migrations as run, but the contents of metadata/tables.yaml hasn't changed.
How do I regenerate that file?
The correct command is hasura metadata export. I tried this initially and the command generated an empty array ([]). It turns out this is because I replaced the tables.yaml with an empty set in order to get Hasura to start.
After running hasura console, rewatching the tables, and resetting the permissions; the metadata export command worked as expected and regenerated tables.yaml.
Related
I have a Hasura project with 3 environments: local, staging and prod
In order to develop locally with the latest data from PROD, I have written a script that dumps and restores PROD db locally
However, when trying to migrate the locally restored PROD db, I run into issues because the migration state is corrupted. Some migrations have been ran on PROD but they appear as not ran locally although it is exactly the same db.
When running hasura migrate status against PROD and local, I do see different results indeed
Howeve,r when inspecting the table hbd_catalog.schema_migrations on PROD and locally it contains exactly the same data...
What's even more confusing is that although PROD correctly marks some of my migrations as ran, their timestamp is not present in the migration table on PROD db...
Is there some other place that Hasura uses to keep track of these migrations?
What version of Hasura are you using? In Hasura 1.x the schema_migrations table was the location for tracking migrations but in in Hasura 2.x this got changed and they are now stored in the hdb_version table as a JSON blob in the cli_state column.
I had similar confusion after upgrading from 1.x to 2.x because the schema_migrations table is still left behind which made me thing it was still in use, but any records there are just vestigial and you can safely delete the table.
I've been following a tutorial to create a database by having a context class, and running the following commands:
dotnet ef migrations add InitialMigration
dotnet ef database update
This did initially work for me, and the expected database was created. Since then I have deleted the migration file and ran the process again, the update command seems to run fine, but when I check the database, the tables have not been created.
If I look in the migration file, I can see that it looks fine and appears to have the correct code in it to create the tables I want.
I don't think I've actually changed anything, so why has the update command stopped working as it did before?
deleting you migration file didn't delete your database
so your database must be still existed however , if your create a new migration with the same name and update your database this will not effect you database since the migration is have been applied to your database
try to delete your database manually from SQL explorer then try update-database
Remove all migrations from your Migration folder in dot net project.
Create a new migration from CLI or from wherever you are making. (dotnet-ef migrations add..)
In the .cs file of this new migration file, comment all the CREATE TABLES commands for existing tables i.e. migration.Create...this one (These will be in the Up method of your migration file)
Just keep CREATE commands for only required tables.
Apply the update.(dotnet-ef database update)
Will work like a charm.
I'm trying to copy the latest artifact from one path to another using Artifactory API.
POST /api/copy/{srcRepoKey}/{srcFilePath}?to=/{targetRepoKey}/{targetFilePath}[&dry=1][&suppressLayouts=0/1(default)][&failFast=0/1]
Let's say I have a few RPMs named: artifact-1.0-1.rpm, artifact-1.0-2.rpm and artifact-1.0-3.rpm.
How to automatically copy the third artifact ?
With the next release of Jfrog's CLI, planned in a couple of weeks, you'll be able to use SORT and LIMIT in the COPY command.
This will allow you to fetch only the latest item\artifact by SORTing by date and LIMITing to the result set to 1.
For now, you can use 2 sequential CURL commands to try and accomplish what you're after:
First use an AQL SEARCH with you're SORT and LIMIT to retrieve the relevant item's path, and then use your COPY command with that path.
Note: the CLI's SORT and LIMIT feature has already been checked in to the CLI's dev branch, so if you wish to use a snapshot you can "download and build" the dev branch from github, and then test if the solution suites you.
I doubt that you can automatically copy all these artifacts in one statement. You can copy the folder but no regex or pattern can defined in copy command.
I am working with doctrine:migrations:diff in order to prepare database evolutions.
This command creates files into app/DoctrineMigrations
Thoses files contains sql commands in order to upgrade or downgrade database scructure.
I want to store those sql commands into the database itself. In fact, i have several instances of databases. If sql commands are store into files, it is a big problem.
I have read somewhere that DoctrineMigrations bundle can create a table called "migration_versions", but i do not manage to find where i have read this...
I cannot really understand what you're trying to do.
Migrations are used when your code needs altered database structure. For example, a new table or a new column. These new requirements for a table or column comes from your newly written code, so it's only natural to place the migrations also as a code in your repository.
How and when would migrations even get to your database? How would you guarantee that migration is executed before the code changes, which use that new structure?
Generally, migrations are used in this way:
You develop your code, add new features, change existing ones. Your code needs changes to database.
You generate doctrine migration class, which contains needed SQL statements for your current database to get to the needed state.
You alter the class adding any more required SQL statements. For example, UPDATE statements to migrate your data, not only the structure.
You execute migration locally.
You test your code with database changes. If you need more changes, you either add new migration, or execute migration down, delete it and regenerate it. Never change the migration class, as you'll loose what's supposed to be in the database and what's not.
You commit your migration together with code that uses it.
Then comes the deployment part:
- For each server, upload the code, clear and warm-up cache, run other installation scripts. Then run migrations. And only then switch to the new code.
This way your database is always in-sync with current code in the server that uses that database.
migration_versions database table is created automatically by doctrine migrations. It holds only the version numbers of migration classes - it's used for keeping track which migrations were already run and which was not.
This way when you run doctrine:migrations:migrate all not-yet-ran migrations are executed. This allows to migrate few commits at once, have several migrations in a commit etc.
We're using Doctrine Migrations to keep the application DB in sync across versions. The app will be installed each time we get a new customer meaning a new DB for each installation.
Now, the new DB will have all DB changes in the migrations file in place but will try to execute the migration files as they are not registered in the migrations table.
What's the best way to handle this situation?
Just after fresh install to fill current schema use this commands:
Create new empty chema of current version
./bin/console doctrine:schema:create
Fill out the migration records with the current version (without actually run the migrations - schema already has current version after first command)
./bin/console doctrine:migrations:version --add --all
This command adds records of the migrations and doctrine:migrations:status will show you that there is no migrations need for the current verions.
Thats all!
As mentioned in my comment, I've successfully created a blank database schema just by using Doctrine migrations. I believe it's necessary to create the empty database first (php app/console doctrine:database:create) and then run the migrations task.
The only potential issue I can think of is that any base data that your app requires to function will either need to be in the migrations files or will need to be inserted separately.
As an aside, running the all the migrations in one go has picked up a couple of small errors that I'd missed when just executing one at a time.
I think you can pick the very first migration class, copy it and rename with just one second before.
So, if your first class is 2016060712284351 you should create a new class called 2016060712284350. This way it is executed just before the real migrations.
In this newly created class you setup your database creating all needed tables. This way, when you run migrations the first thing is done is to create the database with all the tables and then the real migrations are run.
Anyway I'm not sure this is the real way to proceed.
Migrations are needed to update the database schema, but if you are creating a new database for each user, each of the new users will have the new schema as per entities mapping. So a migration is not needed.
You need to run migration only for OLD USERS' DATABASES, am I right?