←back to thread

752 points crazypython | 4 comments | | HN request time: 1.194s | source
Show context
bitslayer ◴[] No.26370635[source]
Is it for versions of the database design or versions of the data?
replies(2): >>26370639 #>>26370870 #
1. skybrian ◴[] No.26370870[source]
Both. Schema changes are versioned like everything else. But depending on what the change is, it might make merges difficult.

(I haven’t used it; I just read the blog.)

replies(1): >>26372168 #
2. fiedzia ◴[] No.26372168[source]
BTW. I wish all databases versioned their schema and kept full history. This should be a standard feature.
replies(1): >>26372555 #
3. codesnik ◴[] No.26372555[source]
keep history just as a changelog to see when and what was changed? or something with versions you actively can revert to? I suppose one of the problems is that changing schema is usually interleaved with some sorts of data migrations and conversion and those I have no idea how to track without using some general scripting language, like migrations in many frameworks which are already there.
replies(1): >>26375118 #
4. fiedzia ◴[] No.26375118{3}[source]
Just storing a changelog would be very useful. I could for example compare db version some app was developed for with current state. Most companies will store schema migrations in git, but doing anything with this information is difficult. Having this in db would make automated checks easier.