search

mudcoders / guildmud

A SocketMUD-based Multi-User Dungeon built and managed by the members of The MUD Coders Guild.
MIT License
26 stars 12 forks source link

Create db.h and db schema update logic #38

Closed rogersm closed 6 years ago

rogersm commented 6 years ago

First path for the Persistence solution.

  1. It moves the db definitions to a different include file (db.h)
  2. Updates db_migrate() in db.c so guildmud updates the db to the latest release on startup.
  3. As part of (2) we add to the database the NEXT_ID filed to have a single generator of id for all the objects the mud will manage. This will be used in the following persistence PR.
zachflower commented 6 years ago

I like this, and was almost exactly what I had in mind for a migration strategy. What do you think about wrapping the actual migration runner in a TRANSACTION, so we don't get half-finished migrations?

rogersm commented 6 years ago

@zachflower That's a clever idea. I had in mind to have simple actions in the schema upgrade SQL action without need of any transaction, but I have to admit a TRANSACTION block will not hurt. I'll update the code it to include it.

EDIT.

I've been thinking about it... what do you have in mind exactly? A TRANSACTION/COMMIT block for each step or to have a single TRANSACTION/COMMIT for all the steps?

I see pros/cons for each option and I think a TRANSACTION/COMMIT for all steps makes more sense.

zachflower commented 6 years ago

This all looks great @rogersm! I think the TRANSACTION/COMMIT for the entire migration was the way to go, rather than for each command. If any point during the process fails, the entire thing gets rolled back, which will protect us against potential failed dependent migrations.