Voice of the DBA

Author: way0utwest

Flyway Tips: Object History

It’s a small change, but a handy one. Flyway Desktop (FWD) now includes the object history for different schema changes, so as you are evaluating how your changes might fit in with others, or you are trying to determine where something broke, you can see a list of historical changes. This post looks at checking history quickly in FWD.

I’ve been working with Flyway and Flyway Desktop and helping customers improve their database development. This series looks at some tips I’ve gotten along the way.

Checking History

In Flyway Deskop, I can see all of my objects on the Schema Model tab on the right side. Here I’ve selected CustProc in the list, and at the bottom I see the current version of the code. However, if you look where my cursor is, there’s a small clock there.

If I click this, I see a blade pop out with history. On the left, I see the various versions. At the top, I have the uncommitted change I just saved. This is shown as the older version on the left, which is committed in Git. My new changes are on the right, with green shading to highlight what I’ve changed in code.

However, maybe I wonder what was the previous change. If I click the top commit (c398a9d), I see this view. Note the red shading on the left, which are the columns I removed. I also have the green shading on the right, where I’ve added a comment and removed a comma. My commit message is at the top with my name and the time (upper right).

I can flip through the various history iterations of code here, just as I did with Git, but I can do this while I’m doing development work in the same place I’ve capturing changes.

I have a “go to Version Control at the top as well, which opens the VCS tab. Here I can commit the change.

Once I do that, my change appears as a new commit for this object in the history.

AI Sparkle

It can be easy to sometimes see the changes made by a developer and understand them. However, sometimes there are complex changes, or you don’t notice something. Here I’ve got a more complex object history.

In the upper right, there’s an AI sparkle next to the “Explain this change”. If I click that, and have AI features enabled, I get an explanation. I’ve zoomed in to see this at the top.

This is a summary of the changes, which in the chaos of work, can be helpful. I get a quick summary.

I wouldn’t just trust this, but instead this guides me along the code to look at what’s been removed and added, and this summary helps me double check that the code does this, and that I understand it.

Summary

This a small improvement, but one that keeps you focused on the work: what changed. No hunting down the changes in Git or changing somewhere else. This also is easier to see than a git diff for me. It also gives me a quick summary where there are a lot of changes.

If you work with Flyway, update your desktop and give it a try. We would love to hear your feedback.

Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today. It works for SQL Server, Oracle, PostgreSQL and nearly 50 other platforms.

Video Walkthrough

Watch me do this in video:

September 28, 2026
Absolute and Relative References

This week I caught a short tale of Reitse trying to migrate a Power BI report from one Tenant to another in Fabric. It’s something that I would consider a common practice, whether it’s from a dev tenant to a prod one, or from a consultant to a client workspace. Moving things around is what we do in the digital world, whether that’s schema structure, a report, a data export, or something else. This is common.

And it should be simple, right? I’m not complaining about Fabric here, though it should be easier. I don’t know if this is a Fabric problem, per se, or maybe it’s a Power BI issue. After all, I should be able to decide and link things in a relative or an absolute manner.

I’m going through this as we test some movement of the SQL Server Central infrastructure. There is a mix of relative and absolute pathing, which breaks the test system. This is similar to the issues I’ve seen when copying files and configuration inside a local machine. Should I really have d:\git\myrepo\flyway.toml, or should this be .\flyway.toml and assume the reference will be in the repo? There’s no easy answer, whether you’re using Flyway, Docker, or any software.

This is a place where the user should think for a moment about the future and what makes sense. Every month I I attach a file from SharePoint to an email to my Finance group. Outlook always asks me if I want a copy or a reference. Often, for internal links I want a link, so that if I edit the file (or the recipient does), we edit the same file. However, in this case, this is a document of record, so I want to know what I sent, without edits. If I edit things, I want to resend it.

Often we want relative references, especially in the Cloud and Internet places, where we might move resources around, and we don’t want breakage. This is common when moving from dev to test to prod, or from one server to another. However, at times, we want absolute references. On the flip side, I want a standard in my SQL Server instances that puts my data files and backup files in standard locations. Data on the d: and e: drives, backups on the z: drive was a standard we used in one place.

I’m not advocating that you lean one way or the other, but think about the purpose of the item and the future possibilities. Sometimes an absolute reference makes sense, and sometimes a relative one works better. If in doubt, I’d pick the latter, but be sure that whatever software or system in which you work supports this.

Steve Jones

September 26, 2026
Get Along

I enjoy listening to Get Along by Kenny Chesney periodically, often smiling to myself. I was reminded of this song recently while talking about careers and the AI impact during VSLive San Diego.

On one hand, most of the people I surveyed or chatted with were using AI to accomplish some tasks. However, very few are using it in a way that would eliminate their positions or do the majority of their work. On the third hand, lots of them worry about their organizations attempting to get by with more AI and less humans in the future.

I think that last one is a natural point of view in the world today. I’m sure plenty of executives are hoping they can reduce their future labor costs with machine assistance. Quite a few are finding that the machine assistance isn’t that cheap, and humans are still needed. I don’t know where this will shake out in the future, but I guess that many of our organizations will shrink a bit and use less developers than they might have now. I also think there will still be plenty of developer jobs, but AI will be used judiciously to supplement the capabilities of workers.

This means workers will need to know how to work with AI effectively and efficiently.

Perhaps there will be new departments and new companies that spring up and create the need for more workers. I hope that’s the case, but I bet a lot of teams will lose some humans and replace them with AI. The cost of benefits continues to rise, and I don’t know that many companies will grow their businesses enough to keep all their humans and spend on AI. That’s adding lots of salary/token costs because of growth. Some organizations will have a lot of growth, but I suspect many companies will see that they have tasks that need humans and tasks that don’t.

The common question from our discussions was “which humans will stick around?”

Technical competency isn’t likely to be the deciding factor. You being a 10x engineer or the best coder might not keep you around. Spotting problem code and better guiding AIs will matter. The mentorship skills you use with junior staffers, and the patience, will become important. Some people are learning those skills now.

The one thing most people agree on is that you should get along well with others. Those soft skills – the ability to communicate, being pleasant, making others feel not only comfortable but wanting to work with you – will matter most. If others don’t enjoy collaborating with you, especially your boss, I can see your position being precarious and potentially slotted for a layoff.

This isn’t to say you can’t argue a point of view or debate an approach. The thing you should remember is that when you do present your view, it is seen as an engaging and spirited debate, not an antagonistic war. People want to work with others when they feel some bond with them. When they don’t, they might be indifferent or even dread interactions. Feeling dread, hesitation, or a reluctance to engage is a sign that someone isn’t a part of a team.

Those who aren’t part of the team might be the easiest to replace with an agent in the future.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

September 25, 2026
Car Update September 2026
Software is hard. While I love our Lucid Gravity, I realize that they are behind Tesla with software. A few of the weird UX and software engineering decisions they’ve made.

This is part of a series of thoughts on cars, just for fun. These are my thoughts and opinions based on my experiences.

Confirmations

When I got the car, the phone-as-key wasn’t working. I could open an app on my phone and unlock the doors and enable driving (two buttons), but I had to select these items. Unlike my Tesla Model Y, these weren’t automatic.

I understand that, as building apps that run with low power and detect things is hard. I’ve had numerous items not work well for doors, devices, etc. though I think Lucid should have made this a priority sooner. However, I’m not trying to start a car company, so what do I know.

However.

Phone as a key seems like table stakes for car software, but let’s ignore that. The big thing for me is the confirmation when I open a door or the trunk(s). Why is there a pop up asking me if I want to do this. Engineers might think, of course, give a confirmation.

For me, if I press a button on the fob, there’s no confirmation. If I hit the button inside the car, no confirmation. Why add one in the software? Or maybe more importantly, why not have this as a toggle the user can enable or disable. Toggles are cheap, they are often implemented anyway for testing, so why not expose them?

There are UI/complexity considerations, but most of us are used to changing settings in the various apps on our mobile phones.

Deep Linking

On the main screen for a Tesla is a set of buttons on the bottom, one of which is a menu. There’s also a settings button. There are 5 (or 6?) customizable buttons, which I can pick a function and then drag that onto the main toolbar, so it’s available. For me in the Tesla, I had:
- Spotify
- Radio
- Heated Steering Wheel
- Energy usage
- Bluetooth
- Cameras (not sure if this was always there)
Everything on the screen is a function/method call in software. Likely an event calling a method, but still. Why wouldn’t we make things available.

On the Lucid, I only have top level categories available: home, fan/climate, seats, charging, nav, media, etc. You can see these below. I can remove some, or add them back, but I can’t change say, media to radio. I always to to the main media screen and then select radio or Bluetooth or Spotify, etc.

Everything is a function, so why not offer linking those functions to quick buttons?

Summary

There are a few other things I don’t like, but I can guess why the software works that way. I am looking to work with the software, and in some cases, stop doing silly things I would have done before and try to let the car do things for me.

I’ve gone back and forth with Android Auto, and while it sometimes gets in my way, if I live with it and accept it, I’m a safer driver. I do less stuff on screens when I should be driving (or mostly paying attention at red lights).

This is still a fantastic car and I look forward to driving it whenever I can.
September 25, 2026