3 ms·

You can't just wipe the slate clean and start over. This is data that needs to be preserved and is a core part of the business. Not even sure how an SDK is rela

by dmak 4y ago

You can't just wipe the slate clean and start over. This is data that needs to be preserved and is a core part of the business. Not even sure how an SDK is related to database migrations?

ChrisMarshallNY 4y ago
It isn't. The title was "migrations." I tend to write my systems in "layers," which makes "migrations" easier. With layers, you can plan a migration in steps. With monoliths, you'd be best advised to pray. We have a "data" migration, coming up; but probably not for a few months. It will be handled in a similar manner. And I have watched "wipe the slate clean" migrations, done, several times. In some cases, they were not deliberate, but the migration screwed up the data so badly, it had to be binned.
- pc86 4y ago
  > The title was "migrations." Are any of the migrations in the article non-data migrations?
  - ChrisMarshallNY 4y ago
    Fair point. I guess the only "migrations" that matter, are data ones. I'm not a "big data" chap, but I have written distributed (franchised) systems, and have had to do many upgrades and transitions, affecting many folks. It's taught me to be forward-thinking in my architecture.
    - dmak 4y ago
      Okay? You don't need to be a "big data chap" to run data migrations. Regardless of your infrastructure and system designs, your business will continue to evolve and the data can outgrow your original database requirements, so there's always a need for a migration even if one is "forward thinking in their architecture"
      - ChrisMarshallNY 4y ago
        Hey, listen. I just read the article, and said to myself: "Self, y'know, this chap is talking about database migrations, which isn't really my cup of tea, but his point is just as valid for codebase and dependency migrations." So I made a point, based on that. It was not my intention to pee in anybody's punch bowl. So I leave the field to you. I yield. I surrender. You win. Have a great day.
    - pc86 4y ago
      One thing that caught my eye in the Spotify screenshot is that there's what is presumably a Python 2 -> Python 3 migration monitor, which is also the only red one. I would typically assume that a code migration would be much more difficult than a data migration, which sort of feeds into that "Python would be the only red migration monitor" idea, even if data migrations are more complex from a making-sure-everything-works perspective.

by dmak 4y ago

You can't just wipe the slate clean and start over. This is data that needs to be preserved and is a core part of the business. Not even sure how an SDK is related to database migrations?

ChrisMarshallNY 4y ago

It isn't. The title was "migrations." I tend to write my systems in "layers," which makes "migrations" easier. With layers, you can plan a migration in steps. With monoliths, you'd be best advised to pray. We have a "data" migration, coming up; but probably not for a few months. It will be handled in a similar manner. And I have watched "wipe the slate clean" migrations, done, several times. In some cases, they were not deliberate, but the migration screwed up the data so badly, it had to be binned.

pc86 4y ago
> The title was "migrations." Are any of the migrations in the article non-data migrations?
- ChrisMarshallNY 4y ago
  Fair point. I guess the only "migrations" that matter, are data ones. I'm not a "big data" chap, but I have written distributed (franchised) systems, and have had to do many upgrades and transitions, affecting many folks. It's taught me to be forward-thinking in my architecture.
  - dmak 4y ago
    Okay? You don't need to be a "big data chap" to run data migrations. Regardless of your infrastructure and system designs, your business will continue to evolve and the data can outgrow your original database requirements, so there's always a need for a migration even if one is "forward thinking in their architecture"
    - ChrisMarshallNY 4y ago
      Hey, listen. I just read the article, and said to myself: "Self, y'know, this chap is talking about database migrations, which isn't really my cup of tea, but his point is just as valid for codebase and dependency migrations." So I made a point, based on that. It was not my intention to pee in anybody's punch bowl. So I leave the field to you. I yield. I surrender. You win. Have a great day.
  - pc86 4y ago
    One thing that caught my eye in the Spotify screenshot is that there's what is presumably a Python 2 -> Python 3 migration monitor, which is also the only red one. I would typically assume that a code migration would be much more difficult than a data migration, which sort of feeds into that "Python would be the only red migration monitor" idea, even if data migrations are more complex from a making-sure-everything-works perspective.