Until now, I used the hasura console to update my database schema (new column, table and manage permissions). Every time a change is made, a new migration is created.
Today I added two columns and updated the permissions (select/insert/update).
For some reason, I deleted and recreated my database. Every migrations worked fine but not the permissions. I have my new columns in my tables but the permissions are not persisted and I can't understand why...
The last time I updated permissions, the metadata file changed but not now. I don't really understand this part of hasura, even with the documentation.
Any idea?
Related
I am not clear how the executeAsync works in Camunda 7.15.0 version.
Using Java code in spring-boot application, I am trying to migrate few process instances from one process version to another using migration plan.
In java code when I use execute() method then the code is obviously executed immediately.
import org.camunda.bpm.engine.RuntimeService;
final MigrationPlan migrationPlan = runtimeService.createMigrationPlan(fromProcessDefinitionId, toProcessDefinitionId).mapEqualActivities().build();
final ProcessInstanceQuery processQuery = runtimeService.createProcessInstanceQuery().processDefinitionId(fromProcessDefinitionId);
runtimeService.newMigration(migrationPlan).processInstanceQuery(processQuery).executeAsync();
But When I use executeAsync() method then I see the batch job waiting in the batches section but does not complete. How to know when will it execute?
Issue can be recreated in https://github.com/firstpostt/camunda-demo-migration. It needs postgres database and credentials need to be given in application.yml
There is an entry in act_ru_batch table. I don't see any entry in act_ru_job table
Can I configure in bpm-platform.xml file to make sure my migration plan runs within next 15 minutes when I use executeAsync() method?
Is there any option to force-trigger the batch from the admin cockpit when needed?
Found the problem. The issue was with Postgres database but I am not sure what is the exact root cause because the issue is not easy to recreate. I dropped the database and created it again from scratch which seems to resolve the issue (I used the same sql scripts again using flyway so nothing changed w.r.t database schema. The only difference I can think of is that after some data is populated already into the tables then I created the unique constraint on camunda tables which might have caused the issue. Now I created unique constraint immediately before populating any data into the tables)
P.S:
I was using unique constraint in postgres Database https://docs.camunda.org/manual/7.5/user-guide/process-engine/database/#additional-database-schema-configuration
I figured out that the issue was with database because I tried with h2 filesystem database(camunda.bpm.database.schema-update as true and spring.datasource.url=jdbc:h2:~/camunda;DB_CLOSE_ON_EXIT=false) and batch worked fine.
Then I used postgres database (without the unique constraint script) and batch worked fine. When I created a new database schema with the unique constraint script then the batch did not work and even if I dropped the constraint the batch did not work anymore
So I dropped the database and created a new database again without unique constraint and then the batch worked fine. After that I added the unique constraint and the batch still works fine.
I am not able to recreate the issue consistently but my guess is that it has something to do with the unique constraint. If you are not using this unique constraint then I am sure that this problem will never occur at all
Several months ago, I was working late and needed to create a new column for a postgres table. I added the column through the command line using the standard heroku/postgres commands. I quickly realized how silly this was, deleted the column and then created the necessary migration to add it.
I recently took that laravel app and created a pipeline with it as the production app. I created a new staging app and set up a database for it. When I ran the migrations, I got an error saying that a column already existed. As you may have guessed, this is the same column that I had messed up before.
Since the migration failed after the database was created, I was able to delete the column in question, rerun the migration, and everything was OK. I do not understand why the column already existed except to guess that it was some artifact of my adding it manually (there was no error in the migrations).
I am worried that this same error will happen when I push the staging code to production and have to rerun my migrations. Obviously, in the production app I can't just delete the column in question as it has data.
Any ideas as to why this would happen and what I could do to fix the issue if it arises when I push the code into production?
I've always thought that if a migration applied with flywaydb is removed (both: entry from DB schema_version table and migration sql file) then application (written in spring framework with flyway in classpath) will crash at startup because of invalid checksums.
Actually (I tested it today) when both migration file and DB entry is removed application starts just fine, which I found a bit confusing.
How does flyway calculate the checksums? Is it based only on content of migration file being applied or previous migrations are also taken into account?
Also, is it safe to remove already applied migrations if both file and table entry is removed?
Many questions here. For your main question, this behavior is controlled by the ignoreMissingMigrations flag. See https://flywaydb.org/documentation/commandline/migrate
Checksums are calculated based on the content of the migrations files (ignoring line-endings due to Git CRLF transformations).
If both a migration file and its entry in the metadata table are removed Flyway doesn't know anything about it anymore. This however doesn't mean it is safe, as it may impact your ability to recreate your database schema later.
so I went to create some migrations of some tables
and was hitting the up arrow and changing the --create"name" but was leaving the class name the same on accident after I already created some I noticed and tried renaming the files and classes but ran into problem I migrated and got errors I tried renaming them back and resseting and rolling back but everything is too messed up I dropped the tables manually and when I try to reset or rollback now I get a table does not exist error is there any easy way to get out of this mess with out having to create a new project?
If you mess up your migrations (can happen if you have migrated and change directly in the migrations), you can always just drop all tables and run a fresh php artisan migrate.
It sounds like you had migrated, and changed the tablenames of some tables. When you do that and try to rollback (reset starts out with rolling back) it tries to drop the tables, but when it gets to the changed tablename it can't find it in the database and you get an error saying the table doesn't exist :)
In my project, current approach is to create database if not already exists using CreateDatabaseIfNotExists and doing seeding initial data from that Intializer as well. I also added Code First Migration support after upgrade to Entity 4.4, so that in the future when we change the modle/database structure we can update client side database without drop their exist database.
However it didn't seems to working well, for example, I am now stuck on design time where forms wouldn't load and the error message is something like The model backing the 'myEntities' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).. But the model and database is indeed the updated version, just seems Migration didn't recognize the database generated by CreateDatabaseIfNotExists, but at the same time all seems working well at run time.
Also after that I noticed that if I let CreateDatabaseIfNotExists initialize a database, Add-migration afterwards will fail and complain that pending migration and ask me to do a update-database. When I try to do a the update-database, it will fail as well because the migration path seems assume the database is in initial setup state and will trying to running all the migration scripts while none should be run as the database generated by CreateDatabaseIfNotExists is indeed sync with current model and should not be migrated at all.
I discovered that there is a MigrationHistory table in System Tables, that table will always save the database initialize history regardless of whether the initializer is CreateDatabaseIfNotExists or MigrateDatabaseToLatestVersion. The difference is that if database is initialized by CreateDatabaseIfNotExists1, everytime the database initialized, the migriationId for that initialize record will be different, butMigrateDatabaseToLatestVersion` will always save same set of migrationId for each of the Migration steps. I guess that is how Entity Framework 5.0 works.
So in the end, I give up and rewrite my DB Access code to seeding the initial database data
in other part of my code rather than the CreateDatabaseIfNotExists or MigrationsConfiguration` class because either suit my need.