I did a simple bar graph to show the status of a db migration. Each bar is a computer with a db file. As I was bored waiting, I added a King Kong hanging from the longest bar.

Running a huge migration on our production db.
Takes 45+15 minutes (migration+tests) on my lappy. So. I'm going to be bored and slightly worried for the next hour.

Hopefully the production servers will be faster.

I HATE TESTING DB MIGRATIONS! SHIT TAKES BLOODY FOREVER!

This one takes 20 freaking minutes each attempt, and I need to run it. yet again.

$@%&!

OMG people please stop being so fucking lazy... help me help you... RN I have multiple support people asking me to fix a bug that they can't even describe (and honestly I doubt it exists) and a fellow developer who refuses to give me a DB or migration to test his patch but wants me to merge it urgently. FOH and die, y'all.

...He hired a shit dev who did the same work in 3 times less than what I asked for.

He's now back crying to fix his Fuck up.

You ask how I know he is shit. He SSH-ed into the server. Worked directly off the production files. Worst of all, he installed phpmyadmin, changed the db structure without even writing a fucking migration !!!

How the hell am I supposed to know what he changed!! It's gonna be a long night 😥

Contex: Working on a c++ frankenstein code (mixture of legacy and new stuff whith things depending on the client using it)

User Story: Migration from oracle to SQLite for half of the DB data

Summoner: One client wants to keep using legacy for now, therefore we need an strategy chooser templated singleton...

Satan 666 = Singletons + Static methods + Different compilation units

Result: 3/4 of the files of the full backend being modified for the migration.

Conclusion: When will be loaded on production company will probably lose many clients due to unspected bugs everywhere.

Insert potato here

Allrighty, so we have a huge migration upcoming. The planning started early this spring. We've split the whole process into separate tasks and estimated each of them. Also marked all the tasks client should take care of itself so save funds and time. All-in-all the whole thing estimated like 4 months if we did it [single dev, tremendous amounts of communication with various parties, buy and prepare the infra, adapt app to the changes, testing, monitoring, etc.] and like a month if client did the tasks we shouldn't be doing. The funding for migration is time-bound and can only be used before December. Cool! We got notified that by the end of April we should be good to go! Plenty of time to do things right!

April comes. Silence. Mid-april we resch out to the client. Since there's plenty of time left migration is getting lower priority to other tasks. Well allright, sort of makes sense. We should migrate mid-July. Cool!

July comes. Client replies that everyone's on vacation now. Gotta wait for August - will do the quicker version of migration to make it on time. Well allright....

August comes. Everyone's vusy with whatever they've postponed during summer. Hopefully we'll start migration in September. Mhm...

September comes. We're invited to a meeting by project funders to explain tasks' breakdown, justify the time needed to make the migration. We're being blamed for surreal estimations and poor organization of tasks as nothing's happened yet... [they were the ones who always were postponing things....]. Moreover, they can only spare 20% of infra resources required for data alone anf they want us to make that enough for all environments, all components, all backups, all databases,... You get the pic.
The leader of the meeting semi silently mumbled to other participants 'Well then I'm afrsid we can't make a full migration in time.. Only partial. That's very unfortunate, very. That's why we should not have incopetent vendors [*glancing at us*]'

somehow we agreed we'll get the resources mid-November and we should be thankful for him bcz he'll have to pull some strings for... us..

I left the meeting with my fists squeezed so hard! But it's okay, we got smth useful: resources and start date. Although it leaves us with less than a month to do smth requiring a month for a sunny-day scenario. Nvm, still doable.

Last week we get an email that resources will be available at the beginning of December [after deadline] and we should start a full migration no sooner than Nov 12. Which leaves us with 50% of our estimated fucking optimistic scenario time and not enough resources to even move a single db.

Fuck I hate politics in dev... Is it wrong for me to want to tie them to a pole, set them on a veeery slow fire and take a piss on them while they're screaming their shitty lungs out? I'd enjoy the view and the scream. I know I would. And while enjoying I might be tempted to take a burning 20cm diameter wooden stick and shove it up their assholes. Repeatedly. Round-robin. Promissing them I'll take it out in 5 seconds and pulling it out after 2 minutes.

Can I?

Switched from PHP 5.4 to 7.1, migration went well except, a seemingly harmless SQL query takes like forever to fetch. At first I thought it had something to do with the DB or the server.

Issue: Previous developer did a sloppy job by using nested sub-queries everywhere.

SELECT
(SELECT foo1 from x1.....),
(SELECT foo2 from x2.....),
.....

Unlike 5.4, PHP 7.1 seems to have 0 tolerance to nested queries and just flat out crashes or takes a stupendous amount of time to load.

Using nested queries is such a bad practice.

One of our projects migrated their file-repository to another one during a major release.

Instead of giving this task to an experienced programmer, they gave it to the head of the respective dev department due to the usual release panic.

Soo.... He wrote the migration tool. It was executed during the release. Everything seemed fine so far.

A few days later. Someone from the above project came to my team due to some "strange behaviour on the production database".
They reported that they couldn't download some of the user's documents due to unknown reasons.

After quickly analyzing the current state of the new file-repository, we concluded that the affected documents did not exist in the new repository.

Then we took a look at the so called migration tool...
Well.. After nearly 30 min. we knew the root cause for that.
They only migrated the first 4 levels of the folder structure. Due to the assumption that "we don't use deeper nesting". (Facepalm)

As the head of their department wrote it, no one seems to questioned it either. Nor did they made a code review and ended up with a tool with hard coded urls to the production db, no version control, no build tool, no ci, nothing. Breaking nearly every possible company standard.

However.. That's not it. When analyzing their migration tool we noticed another even more dangerous thing.
They mixed up the id generation of the migrated documents resulting in a random assignment between customers and documents. Which is quite bad as this contains sensitive information. E.g. passports

They offered us quite a nice amount of money to fix this until EOB. We declinded as it was simply not possible in that time, but agreed to support them with the new tool.

After some time I heard that they migrated production again. And they fucked it up again. They never talked to us after we offered them support...

The third and final migration was written by us. Not only migrated it correctly. It was also way faster. By factor 20.

In the end we haven't gained anything from this rushed project as the penalties were piling up due to this fucked up migration.
After all this time I'm not sure who is to blame. In my opinion, partly all of them.
Head of department who can't and shouldn't code.
Seniors who didn't review the code and didn't ask for help.
Release mgmt who put way too much pressure on the devs.

Mine: not listening to early warning sings that shit won't work. As a result we implemented the wrong technology and had to roll back after a month in production. Lost some customers data, though we had backups, so it was just a delta of a day or so. Still, not pretty, had a rough night writing scripts at 3am to check data validity after.

I will throw in another one from a colleague of mine. He was running some database migrations and ended up pointing the DB migration tool to production by accident. Oops. That one required a restore as well, if I remember correctly.

get to the office at 5:45AM to do a migration because the client doesnt want to automate it.. but pays extra for the inconvenience...

Good to see people are learning and don't use hard coded credentials and store them in the DB.
Now they just have to quit putting them into migration files

Come on, WordPress! Why are you such an asshole? I just want to migrate and move on with my life.
Is it because I started with Joomla? Is it because I cheated you with Flask?
Can you please, please be nice to the same db you made? Am I asking to much for?

I so hate working with legacy db code! I wish I could migrate all to entity framework but the migration is a pain in the ass and would take hours which the client wouldn't like.

So many choices for backend I'm fucking confused. Yesterday, I tried Django and i found it little similar to RoR(in generating things, db migration things).
I'm currently working in NodeJS.
I even don't know should I rant or cry.
And of course frontend is another thing same like this.....
And I'm not much experienced to differentiate them and know which is better and where it will fit.
Can anyone tell me in simple way which framework fits where?

I thought today was a good day to look at how I will deal with database migrations for this node.js/sql-server application. I read up docs for a few migration frameworks but the ones I found seem to make things too complex.

I am tempted to just roll my own by storing a db version in a table, numbering .sql scripts in a folder and running all the higher numbered scripts when the application starts.

Anyone know is there any gold standard for this sort of thing or anything to watch out for?

Dont be that guy, ok. Just clean up your shit and don't let shit go through you.
I will git blame you. I will judge you.
#leaveitbetterthanyoufoundit

Why does Microsoft make entity migration default and every tutorial show them? I have other ways of migrating my db schema changed. Newbies come to me with this cluster already in motion and I have to help straighten it out. Then the newbie says "why do all the tutorials show it". I say because the people making the tutorials are trying to quickly create content for a tutorial.

just 'Hello world' me trying to make a restful api.
*Got Ktor, loved the koltin, hated the deploy, quit.
*Got Django, loved the python, hated the sql migration, quit.
*Got Node, loved everything, hated mongo, can't quit now...
*Got Firebase DB now, I feel the hate monster...ghostly voices, saying, Work my slave, build it... dont stop, 'cause we're right behind you...

....and we're waiting for you

DB migrations give the chills.

This one went well. It worked as expected but that "uneasy" feeling lingers...