Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using the expand and contract pattern for schema changes

prisma.io

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Using the expand and contract pattern for schema changes

#31

Post by mayanraisins »

leetrout wrote: post #2

I use this example when I speak about and teach devops trainings. I call it the migration sandwich. (Nothing to do with the cube rule). A piece of bread isn't a sandwich and a single migration in a tool like alembic isn't a "sandwich" either. You have a couple layers of bread with one or several layers of toppings and it's not a sandwich until it's all done. People get a laugh out of the "idiot sandwich meme" and we…

I’ve always paired this with the strangler pattern.

“In programming, the strangler fig pattern or strangler pattern is an architectural pattern that involves wrapping old code, with the intent of redirecting it to newer code.”

https://en.wikipedia.org/wiki/Strangler_fig_pattern

Re: Using the expand and contract pattern for schema changes

#32

Post by UltraSane »

marcosdumay wrote: post #23
mcdonje wrote: post #14

Earlier quoted context omitted.

This is the same pattern as versioning, but with an extremely short sunset for the old version.

It's actually not. Versioning is a concept where each version lives in non-intersecting time intervals. This concept is completely focusing on the fact that your structures lifetimes must absolutely have non-empty intersections. It's close to the opposite.

It is often necessary to use multiple versions at the same time

Re: Using the expand and contract pattern for schema changes

#33

Post by ambicapter »

davedx wrote: post #17

I use Prisma on almost all my node.js projects these days, and I wish that part of schema migrations was also automated by Prisma. But last I checked, it doesn't even rename columns properly. I feel like maybe they should invest more R&D in their migrations technology? The ORM is pretty great.

What do you find good about Prisma?

Re: Using the expand and contract pattern for schema changes

#34

Post by 8note »

im not sure about the name, but this is a great little doc for introducing junior devs to migrations.

the only thing i would add is a minor and major version changes, so its clear how the different class ent stages are labeled/how you track when you're ready to backfill

Re: Using the expand and contract pattern for schema changes

#35

Post by afiori »

mcdonje wrote: post #14
leetrout wrote: post #2

I use this example when I speak about and teach devops trainings. I call it the migration sandwich. (Nothing to do with the cube rule). A piece of bread isn't a sandwich and a single migration in a tool like alembic isn't a "sandwich" either. You have a couple layers of bread with one or several layers of toppings and it's not a sandwich until it's all done. People get a laugh out of the "idiot sandwich meme" and we…

This is the same pattern as versioning, but with an extremely short sunset for the old version.

That is a very reductionist view and not particularly useful either. It shares elements with versioning and you could likely implement this using explicit versioning, but it is completely independent of it.

The main difference I see is that of focus here the focus is to migrate a database without downtime or excessive global locks, keeping multiple versions of the schema is a detail.

Re: Using the expand and contract pattern for schema changes

#36

Post by 8note »

vvern wrote: post #26
isuckatcoding wrote: post #16

Ok hear me out. What if this whole process was statefully managed for you as an add on to your database? Like you essentially defined the steps in a temporal like workflow and then it does all the work of expanding, verifying and contracting.

It should be this way. Clients should have some protocol to communicate the schema they expect to the database probably with some versioning scheme. The database should be able to serve multiple mutually compatible views over the schema (stay robust to column renames for example). The database should manage and prevent the destruction of in use views of that schema. After an old view has been made incompatible, old c…

> The database should manage and prevent the destruction of in use views of that schema. After an old view has been made incompatible, old clients needing that view should be locked out.

this is the interesting part where the article's prpcess matters. how do you make incompatible changes without breaking clients?

Re: Using the expand and contract pattern for schema changes

#37

Post by pphysch »

chrisweekly wrote: post #24
davedx wrote: post #17

I use Prisma on almost all my node.js projects these days, and I wish that part of schema migrations was also automated by Prisma. But last I checked, it doesn't even rename columns properly. I feel like maybe they should invest more R&D in their migrations technology? The ORM is pretty great.

Lack of reasonable support for migrations turned me off to Prisma when I first encountered it (in a KCDodds Remix app circa 2021-ish). I'm surprised that's still unaddressed.

Lack of support for running migrations, or generating migrations?

Re: Using the expand and contract pattern for schema changes

#38

Post by Normal_gaussian »

leetrout wrote: post #2

I use this example when I speak about and teach devops trainings. I call it the migration sandwich. (Nothing to do with the cube rule). A piece of bread isn't a sandwich and a single migration in a tool like alembic isn't a "sandwich" either. You have a couple layers of bread with one or several layers of toppings and it's not a sandwich until it's all done. People get a laugh out of the "idiot sandwich meme" and we…

Evens between odds. Where even schema versions are migrations and 'divisible between two'.

But green/blue and A/AB/B I've used before to discuss the same.

Re: Using the expand and contract pattern for schema changes

#39

Post by mcdonje »

afiori wrote: post #35
mcdonje wrote: post #14

Earlier quoted context omitted.

This is the same pattern as versioning, but with an extremely short sunset for the old version.

That is a very reductionist view and not particularly useful either. It shares elements with versioning and you could likely implement this using explicit versioning, but it is completely independent of it. The main difference I see is that of focus here the focus is to migrate a database without downtime or excessive global locks, keeping multiple versions of the schema is a detail.

Seems like you agree with my assessment.

Re: Using the expand and contract pattern for schema changes

#40

Post by afiori »

mcdonje wrote: post #39
afiori wrote: post #35

Earlier quoted context omitted.

That is a very reductionist view and not particularly useful either. It shares elements with versioning and you could likely implement this using explicit versioning, but it is completely independent of it. The main difference I see is that of focus here the focus is to migrate a database without downtime or excessive global locks, keeping multiple versions of the schema is a detail.

Seems like you agree with my assessment.

:(

Things can have similarities without being the same. Also not being unique is not a moral failure.

I think I am failing to understand your stance.

Post reply on HN