V2

[jdrake]

@ssantana-ns @bgimby-ns

This is a proposal for a pynocular v2 implementation. I assume that we'll keep this branch open for a while as we test out v2 before merging. We can still release new versions to pypi.

There are a few goals for this proposed v2:

1. Provide better model attribute typing support by using regular inheritance instead of the decorator. The PR Better static analysis support #19 uses the same approach.
2. Refactor the model implementation to allow for multiple backends. This gives the ability to add an SF API integration later. We will need to use the SF UDD to store entities instead of Postgres in production. The hope is that we can keep using pynocular and abstract the storage backend. A nice side benefit of this approach is that we can treat the in-memory implementation as a first-class backend and not have the patch_model decorator need to define a bunch of private functions.
3. Use the databases package instead of our layer on top of aiopg. This package has a simple interface on top of asyncpg that should work for us. I'm not sure if there are things about asyncpg that don't work for us.

Check out the test module for how it works. The basic usage goes as follows:

1. Do what you need to do to set up the backend (in the case of SQL it's establish a connection)
2. Instantiate the backend, providing it with backend-specific arguments
3. Set the active backend in the aio context using the set_backend context manager. Note that in a real FastAPI service, this stuff will happen once in a middleware function so that application code can just use the DatabaseModel classes as they do now.
4. Call DatabaseModel methods

async with Database("postgres://localhost:5432/postgres") as db:  # (1)
    with set_backend(SQLDatabaseModelBackend(db)):  # (2) and (3)
        await Thing.select()  # (4)

Notes:

• ⚠️ Using asyncio.gather should no longer be used within a transaction in pynocular v2. See Cannot perform concurrent async queries on same database connection. encode/databases#125 (comment)
• All original tests pass. I didn't alter any logic, just the context of the database and the backend.

Things left out:

• Nested model support, since it's not used and adds complexity. I think it should be ok to add it back in but we'd have to be careful about breaking the model/backend abstraction. I vote that we leave it out unless we really need it.

[ssantana-ns]

some questions but high level LGTM