search

adriangb / asyncpg-trek

Simple migrations system for asyncpg
MIT License
8 stars 2 forks source link

Split SupportsBackend into SupportsBackend and SupportsBackendExecutor #5

Closed adriangb closed 1 year ago

adriangb commented 1 year ago

Closes #4

adriangb commented 1 year ago

@euri10 so the reason a connection was being passed around was to make sure everything ran inside a transaction. Your feedback makes me think the root of the issue is that SupportsBackend is doing too many things. I think splitting it into two interfaces like this makes it a lot easier to understand what's going on and how it should be used. Now we have 2 interfaces:

  1. SupportsBackend which is responsible for (1) creating a SupportsBackendExecutor (i.e. connecting to the db and/or creating a transaction) and (2) creating an executable function from .sql file.
  2. SupportsBackendExecutor which is responsible for actually executing things and should internally have a connection wrapped in a transaction. Since this connection is now always wrapped in a transaction (or whatever the backend needs) it can use self.connection instead of having the connection as a parameter to each method, which is what you had originally proposed for SupportsBackend.

I also renamed execute_sql_file to prepare_operation_from_sql_file which I think makes it's usage clearer.

How does this sound to you?

euri10 commented 1 year ago

this is way cleaner yep !