0

I'm importing data from older website to new one using database migrations. I have created first as one of first steps of development phase of new site. Then I planned to create another one, that will do final data import at the end of development process.

I was then faced with question, what will happen, if another import will be required a bit later?

Since (for many reasons) we cannot afford for a better solution (like a full installer, able to migrate current data at any point in time) and since such situation have small changes to arise and won't happen again. I suggested, that in this case we should copy import migration on top of all others and execute it once more.

In reply I was suggested, that I should rather create a recurring migration. I.e. the one, that updates migration table in database at the end of migration process, changes its own timestamp and thus forces migration system to "think", that there's always a new migration to be applied on top of all others.

I was a bit surprised with such suggestion. Is it wise and secure to create such thing?

  • 3
    Are you using the term "database migrations" in a generic meaning, or are you having the term in mind like it is used in context of a specific technology like entity framework? – Doc Brown Mar 24 '15 at 7:16
  • I'm using database migrations in Yii and Yii2 PHP frameworks. However, that shouldn't matter (?) as I'm asking for a general rule of a thumb here (that's why posting on Programmers, not on SO). – trejder Mar 24 '15 at 9:14
  • 1
    You assume everyone knows how this kind of "database migration system" works. But in fact, what you are asking may depend on knowing the details of your framework (at least that's what I would expect). – Doc Brown Mar 24 '15 at 9:41
  • Yes, you're right. And sorry. In Yii, the migration system works like this: each successfully applied migration is added to internal migration table in database, which assures, that each migration wil be applied only once. This, of course does not cover migrations, that fails at any point. Therefore, to implement, what I was suggested, such recurring migration would have to tamper with timestamp in that internal migration table, to make itself "always on top". Hope, that clears some doubts. – trejder Mar 24 '15 at 14:03
2

If I got you correctly, you need to migrate just data from a production one database to a development database, and you might have to repeat that process a few times. So as long as you implement the migration in a repeatable, idempotent manner, that should be not much of a problem. The most simple solution might be to clear all previously migrated data from your development database before a new migration, but you might not be happy with that due to performance reasons, or because you have some data in your development database which might be kept there. If that is the case, you will have to design some synching mechanism between those two database, or at least a mechanism to keep or recreate the data in the development DB you do not want to be deleted.

What I cannot tell you is if fiddling around with the time stamps of your migration table will be a problem - for this one needs to know the gory details of your framework.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.