adriangb / asyncpg-trek

Simple migrations system for asyncpg

👋 Hi I'm Adrian

Python and Rust developer. I work on infrastructure, backend and databases.

Projects

🎁 Project	⭐ Stars	📚 Forks	🛎 Issues	📬 Pull requests
SciKeras
Xpresso: a modern Python web framework
di: pythonic dependency injection
graphlib2: Rust port of graphlib
routrie: fastest Python HTTP router
pgpq: bulk load Parquet data into Postgres
pgjobq: job queues on Postgres

Contributions

🎁 Project	📄 Contribution
Pydantic	Maintainer.
Starlette	Maintainer.
httpx	Maintainer.
TensorFlow/Keras	Fixes to model serialization, compatibility with pickling
CPython	Fixed bug in Protocol.__init__. Added logging features.
GeoPandas	Multi-backend spatial indexes, nearest neighbor spatial joins
BetterProto	Rewrote parser to use data driven AST-like approach
Poetry (package manager)	Added CLI options and tweaks to installing to enable use in monorepos with optimal Docker multi-layer caching/td>

asyncpg-trek's Issues

More complete version management

While there's a lot of things, I don't like about Alembic I do think they have a pretty solid data model for versions: https://alembic.sqlalchemy.org/en/latest/branches.html. It'd be really interesting to see what concepts we can pick up from them, maybe while still keeping migrations as edges not vertices.

Release on pypi

Hi,

Thanks for this lib! I like the minimalist approach and put it to use.

It would be nice to have this package published on pypi. I see your CI should do it but it seems broken.

Thanks again!

Default schema for the migrations table

Currently the public schema is the default for creating the migrations table, there doesnt seem to be a way to create it elsewhere.

I'd be tempted to say it is a bad idea because:

1. you may have another migrations table inside that public schema and it leaves you no options.
2. running execute on a schema where there is no migrations table will fail

What do you think of this: asyncpg-trek creates its own schema to handle migrations, and uses a migrations table inside it, low chances of conflicts, and you are able to run migrations on others schema, asyncpg-trek always knows where to find its migrations table