List view
trying to implement as much of rogue run management in sql as possible complete with rls reference the rules from the wiki for that other game stuff that you're pretty confident doesn't need relations can live inside json and use postgres json functions to avoid migrations today investigating with flyway how to better support development stage migrations in sql - for example, should it be in its own schema until it is promoted to production? with normal columns, work with them in spellsource_development, then when you are done with everything, make the migration happen in the spellsource schema or use "dash dash watch" the end goal is to generate a graphql client whose mutations correspond to the actions people will take document how to make changes to the business logic of the rogue run
No due date•0/1 issues closed