mirror of
https://github.com/fnproject/fn.git
synced 2022-10-28 21:29:17 +03:00
96aa2a67ae
code is feature complete in the general sense, with minor TODO left. this is just a patch with 'migratex' and does not use it for fn's migrations yet, would like to get feedback prior to doing that. presenting: A migration library loosely based on pressly/goose and mattes/migrate design, that does migrations across a smattering of sql databases by only accepting a `*sqlx.DB`. why? * goose didn't support kindly allowing us to rebind transactions based on a given db to various dialects or offer oracle support * goose didn't support locking the db (maybe not needed with tx? it's late.. we may want to lock the whole db eventually?) * goose requires us to do semi-complex migration to it from mattes/migrate * mattes has stepped down as migrate maintainer and the project is in flux * mattes/migrate did not allow us to define migrations in go and rebind to different dialects, an issue since we need to insert ids in our own format and can't define this in sql * neither handled context plumbing and risked issues there for various reasons (deadlock, etc). * I think I'm forgetting 1 or 2 in the style of goose, this lets us define `*sqlx.Tx` up and down funcs in go code, but uses mattes' migration table so we don't need to migrate that and retains its lock behavior with added tx sugar and less errors. most importantly, this code is terse, leveraging sqlx to support a lot of sql dbs (unlike mattes) and we control this. there is one useful TODO to handle migrations failing at startup more gracefully, in prod stuff like that will be nice to have. open to discussion of putting in a separate library, the landscape of go sql migrators is... really something. TODO make test suite and test against sqlite3, pg, mysql [, oracledb] like we have for our own unit tests. I'm thinking it's faster to wire up through there and use our bevy of migrations?