I'm using code migrations in code first. I modified one of my models (domain class) and changes were picked up when I added a migration. So far so good. Now is the part where I may be doing something wrong:
I made additional changes making the previous modification irrelevant.
I deleted the migration and tried to re-scaffold, I got an empty migration. I understand now that the database tracks migration history. So I understand why this was stupid.
My next step was to delete the rows in the database- it also sounds like this is not a good idea. The appropriate way to "step-back" is to do Update-Database -Target:{MigrationName}
Trying both of these I am still getting an empty migration. I also tried dropping the database and updating to the migration before mine.
My google/SO foo has failed me. What I think is happening is that VS/Entity is not detecting changes in my model and I'm not sure what the trigger is. Can someone help me out?
I had a similar problem. My solution was to just go forward with a substance-less migration happening. The only change it makes is adding a record to the __Migration table, but I am living with that and just moving forward.
Related
I have this structure of migration of code first approach
I deleted the previous database and wants code first to create it again, but when I am doing update-database it is not running all the scripts and leaving first three migrations and because of it, it is failing because all the dependencies are not present
You see it is just picking up three migrations leaving the first three.
Earlier this used to work. What wrong might be going on? Somewhere it is still storing that the first three are already run while they are not since database itself doesn't exist and it is creating the database for the first time
Found the reason.
I changed the namespace of last three and so it was picking up only those and not the first three.
Just changed the namespace of first three also and it worked :)
I'm experiencing the following issue:
org.flywaydb.core.api.FlywayException: Validate failed: Detected applied migration not resolved locally: 1.44
That happened when I understood that the data that I added in 1.44 is invalid and I don't want to deal with it on old environments, but on new environments I don't want this data. I want the data that I will insert within new migration(e.g. 1.48).
If I change old migration it will fail on old envs due to checksum;
If I leave it, on new envs I will have invalid data from 1.44;
How can I delete it so that I accomplish what I need and not to get an error? What's the correct way?
This questions is related to Best pratice: How to modify flyway migration script after it has been used
The basic answer is: don't delete once it's been applied
It doesn't matter if during the migration process some intermediary state isn't exactly what you want, as long as the final one (1.48 in your case) is correct.
Now if you really need to delete this migration, ask yourself whether replacing it with an empty file could also do the job. If yes you could then follow the advice I gave here: https://stackoverflow.com/a/35491545/350428
Now if that's still not enough and you really really need to delete this migration, delete the file and patch up the flyway_schema_history table by hand to make it consistent again. This is risk-prone and should be an absolute last resort solution.
you can UNDO your migration: UNDO flyway migration
What are the practical advantages of Doctrine Migrations over just running a schema update?
Safety?
The orm:schema-tool:update command (doctrine:schema:update in Symfony) warns
This operation should not be executed in a production environment.
but why is this? Sure, it can delete data but so can a migration.
Flexibility?
I thought I could tailor my migrations to add stuff like column defaults but this often doesn't work as Doctrine will notice the discrepancy between the schema and the code on the next diff and stomp over your changes.
When you are using the schema-tool, no history of database modification is kept, and in a production/staging environment this is a big downside.
Let's assume you have a complicated database structure in a live project. And in the next changeset you have to alter the database somehow. For example, your users' contact phones need to be stored in a different format, not a VARCHAR, but three SMALLINT columns for country code, area code and the phone number.
Well, that's not so hard to figure out a query that would fetch the current data, separate it into three values and insert them back. That's when migrations come into play: you can create your new fields, then do the transforms and finally drop the field that was holding the data before.
And even more! You can even describe the backwards process (the down migration), when you need to undo the changes introduced in your migration. Let's assume that someone somewhere relied heavily on the format of the VARCHAR field, and now that you've changed the structure, his piece of code is not working as expected. So, you run migration:down, and everything gets reverted. In this specific case you'd just bring back the old VARCHAR column and concatenate the values back, and then drop the fields.
Doctrine's migration tool basically does most of the work for you. When you diff your schema, it generates all the necessary up's and down's, so only thing you'll have to do is handle the data that could be damaged when the migration is applied.
Also, migrations are something that gives other developers on your team knowledge on when it's time to update their schemas. With just the schema-tool, your teammates would have to run doctrine:schema:update each and every time they pull, `cause they wouldn't know if the schema has really changed.
When using migrations, you always see that there are some updates in the migrations folder, which means you need to update your schema.
I think that you indeed nailed it on Safety. With Migrations you can go back to another state of the table (just like you can do in Git version control). With the schema update command you can only UPDATE the tables. There is no log kept for going back in case of a failure with already saved data in those tables. I don't know exactly, but doesn't a migration also saves the data of the corresponding table that's being updated? That would be essential in my opinion, otherwise there is no big reason to use them.
So yes, I personally think that the main reason for using migrations in a production environment is safety and maybe a bit of flexibility. Safety would be the winner here I think :)
Hope this helps.
edit: Here is another answer with references to the Symfony docs: Is it safe to use doctrine2 migrations in production environment with symfony2 and php
You also cant perform large updates with plain doctrine migration. Like try to update index on 30 mln users database. As it will a lot of time while you app will not be accessible.
I'm having a recurring problem in AX when trying to create custom tables with relations. In short, the field definitions in the relations keep "disappearing".
I have 6 custom tables, with a total of 10 or so relations between them. Every time I compile, I get at least one error saying "Relation incomplete due to missing fields". I remove and re-add the relation, only to have it error out again later.
I have tried a database sync and an incremental CIL build. Has anyone seen this before? Any suggestions on how to fix it?
Well I am very pleased with your question!! That confirms I am truly not the only one in the world having this problem.
Let me tell you what I already tried.. (Please also check the question I have posted that is related to it)
We are having the same issue within our build process. There, an XPO is imported into Ax and half of the tables is missing fields in relations. Importing the same XPO a second time solves most of the missing fields troubles, but does not fix all of the things going wrong with XPO imports.
I have already contacted some people I ran into from Microsoft and they are having a look at this one. Also, we logged an incident so that we also follow the official Microsoft flow for incident logging.
I will try and update this post here with the response I get from Microsoft.
Just wondering if any one might now how to fix this issue.
Every part of the databroker is created and also all the database connectivity is functional.
But once we try to place them together we come up with a error saying cannot create Null Databroker.
The thing that is really strange is that we have databrokers that are basicly the exact same working.
Can any one shine some light on this issue?
We worked on this together today. We did three things to troubleshoot and fix the problem:
we changed the calling workflow so that the dataset is refreshed inside the show-screen tags (previously, this was done before the screen was called).
we refreshed the dataset (a H2 db) and connected the database (before, it showed as pool not open)
we changed the database name to main
It is working now.
"Null databroker" suggests that the broker was not created correctly, although it doesn't look like that was the case since you don't mention having to modify it to get it to work.
In these cases it can be useful to look at the error logs through the admin app to see if there are errors being thrown at some time other than compile time.