In previous posts, I discussed how we can use Testcontainers to more easily test code that interacts with a MySQL Database and code that interacts with MySQL Document Store. In yet another post, I demonstrated how to manage database migrations using Knex. This post will show how we can leverage Knex to incorporate database migrations into our testing workflow.

Ask anyone who has had a conversation with me over IM or email, and they will tell you I am a horrible typist. I was never a great typist, but was much better in high school. After graduating, it would be about 13 years before I would need to type again. So, it was like learning all over again.

I would like each and every one of you to join me and my good friends, Todd Sharp and Ray Camden, when we launch our new live stream, The Undefined Show, on September 11, 2023 at 8:00 PM Eastern. We will discuss a broad range of topics, primarily related to tech, coding, developer relations, and anything else that comes to mind.

As all developers know, one of the most critical parts of any project is tracking database changes (or migrations). These changes will likely need to be applied in a particular order, and they need to be applied to every environment in the development workflow. We should also be able to roll back these changes should things not go as expected. Knex (pronounced like konnex) can help us manage these migrations, roll back changes, and assist in applying them to different environments.

In a previous post, I talked about how we can use Testcontainers to help make it easier to write tests for Node applications that interact with a MySQL database. In this post, we are going to discuss how we can write tests for Node applications that interact with MySQL Document Store - again using the MySQL Module for Testcontainers.

Over the years, I have become obsessed with writing code tests. One big pain point with writing tests is testing code that interacts with a database. In this post, we are going to talk about some of the difficulties that may be encountered when writing tests for database interaction and how we can use Testcontainers to mitigate those issues.

In a recent post I talked about how we can move data from MySQL running in AWS to a MySQL HeatWave Database instance running in Oracle Cloud Infrastructure (OCI) with just two commands using MySQL Shell. In this post, I will show how we can use a similar process to move data from Microsoft Azure to OCI.

In previous posts, we talked about how we can use MySQL Shell to dump and load databases and how we can dump data to and from Oracle Cloud Infrastructure (OCI) buckets. In this post, we are going to show how you can use MySQL Shell to dump data from a MySQL RDS database to an S3 bucket and then load that data to a MySQL HeatWave Database instance running in OCI - and with only two commands.

In a previous post, we discussed how you could use MySQL Shell to dump and load data using a multithreaded process. At the end of the post, I mentioned it was possible to dump data to and load data from cloud services such as Oracle Cloud Infrastructure (OCI). In this post, I will show you how to perform these data dumps and loads using OCI Storage Buckets.

MySQL Shell is a powerful command line interface for connecting to and managing MySQL instances. One feature of MySQL Shell’s Admin API is being able to dump specific tables (or a subset of data in a table), dump one or more complete schemas, or dump an entire database instance and then restore those dumps as needed. It has the added benefit of doing this in a multithreaded process to make it more efficient.