Hot Swapping Data Models – DEV Community

Picture by Jandira Sonnendeck on Unsplash

Patrik : “So, we have to monitor the place our workers work. Can we try this?”

Devin : “Like, simply what retailer every individual works at? Not too exhausting. Does anybody work at a couple of retailer? Like a regional supervisor or one thing?”

Patrik : “No. That is not doable. Every worker works at precisely one retailer.”

Devin : “Alright, simple sufficient. I am going to work one thing up this week.”

…Later…

Patrik : “Devin! We have been loving the worker tracker you constructed, thanks. Only one little issue-“

Devin : “Let me guess.”

Patrik : “We do want some workers to be marked as working at a number of shops. Can we make that change?”

Devin : sigh “Yeah, let me schedule a upkeep window to make the structural adjustments to the database-“

Patrik : “No, we will not have any downtime for this app. Everybody must run their experiences. We have to make the adjustments with no upkeep window.”

Devin : “Uhhhhhh….”

Devin : Googling “The way to make database adjustments with no downtime; Migrate tables with out downtime; The way to scorching swap an information mannequin”

Don’t worry Devin! Altering fashions with out downtime, whereas tedious, might be completed moderately simply. First, allow us to take a look at the place we have to get to:

Diagram of an employee table in a many-to-many relationship with a stores table via a employeestores join table

And bear in mind, the place we’re:

Patrik’s necessities pair as much as be a one-two punch: change the construction of our database, carry the pre-existing knowledge into the brand new mannequin, and all with none interruption of service. I’ve used six easy steps to perform simply that, greater than as soon as, the place there could possibly be zero interruption of service and there could possibly be zero knowledge loss or corruption. Right here is how I do it:

  1. Implement new fashions
  2. Write to each fashions
  3. Backfill outdated to new
  4. Learn from new fashions
  5. Cease writing to outdated fashions
  6. Take away outdated fashions

Or IWBRSR for brief (alright, alright I am going to cease). That is it. That is the entire article. Easy, however efficient.

Working via Devin’s conundrum, our six steps would work out like this. First, Devin should add the be a part of desk we’d like for the many-to-many relationship between workers and shops. Nevertheless, Devin doesn’t take away the outdated overseas key from workers to shops (but).

Diagram of an employees table in a many-to-one relationship with a stores table while also being in a many-to-many relationship via a employeestores join table

With this database construction change made; Devin now begins adjusting the code wherever an insert, replace, or delete is made that impacts the overseas key from workers to shops to additionally insert, replace, or delete a corresponding employeestores report. (These code adjustments don’t even have to all be in a single launch; something not accurately mirrored between the outdated and new fashions will probably be dealt with by the following step).

After these adjustments, Devin has accomplished steps 1 and a pair of. Devin can now put together a backfill. For every relationship that the outdated overseas key has that the brand new be a part of desk doesn’t have, Devin will create a row on the be a part of desk between workers and shops. Since all new exercise retains the relationships that the brand new be a part of desk and the outdated overseas key have in sync (from the code adjustments of step 2), as soon as Devin completes this backfill the outdated mannequin and the brand new mannequin are good mirrors and can keep good mirrors of every others’ knowledge.

At this level, it could be a good suggestion to pause for a step 3.5 the place we examine the database to ensure the brand new and outdated fashions are in truth good mirrors of one another (like I simply claimed).

As soon as happy, we will transfer on to step 4 and the work will probably be downhill from right here. Devin begins making code adjustments wherever workers and shops are queried to make use of the brand new be a part of desk as a substitute of the outdated overseas key. (Like step 2, this additionally doesn’t should be launched without delay; for the reason that outdated and new fashions mirror each other, studying knowledge from one provides the identical outcomes as studying from the opposite till step 5).

Step 5, Devin is sort of completed! At this level, the brand new mannequin successfully runs the appliance (being written to and browse from). Devin can safely go to these locations they modified in step 2 and take away the inserts, updates, and deletes to the outdated overseas key. (Once more, this doesn’t should be completed in a single launch).

To place the cherry on prime, Devin goes in and drops the outdated overseas key column from workers. Finishing step 6 and leaving Patrik with what they needed, with completely no downtime!

Diagram of an employee table in a many-to-many relationship with a stores table via a employeestores join table


Now, this was a considerably contrived and easy instance. When doing this for actual many, many issues can come up in every step. However, the steps are precisely the identical! They work nicely as a result of every step might be completed in components and redone, little by little, iteration by iteration, till the step works accurately and the following step might be undertaken. So bear in mind, IWBRSR:

  1. Implement new fashions
  2. Write to each fashions
  3. Backfill outdated to new
  4. Learn from new fashions
  5. Cease writing to outdated fashions
  6. Take away outdated fashions

Add a Comment

Your email address will not be published. Required fields are marked *