I have found these related issues/pull requests
N/A
Description
As tests need a user with elevated permissions, the docs mention superuser. I would like to be able to specify a dedicated test user to maintain the 'principle of least privilege' for existing production and development users.
I was hoping async fn(PoolOptions<DB>, impl ConnectOptions<DB>) -> Ret would satisfy this request by granting access to ConnectOptions before the pool is created, but I couldn't get it to work, and it seemed to fail before the body of the function is run in my partial testing.
If this is the right course of action and the resulting failures were simply something on my end, do let me know, and I'll investigate further. I wanted to check first before spending more time fighting the tests.
Prefered solution
DATABASE_URL_TEST overwrite with DATABASE_URL as a fallback, so as not to introduce breaking changes.
Alternatively, a change to async fn(PoolOptions<DB>, impl ConnectOptions<DB>) -> Ret to allow alternative connection, assuming my failure wasn't at the fault of my codebase.
Is this a breaking change? Why or why not?
No, current behaviour can be maintained if desired, and if the macro was updated regarding the function signature, then populating the arguments with the existing DB connection would also maintain existing behaviour while adding more flexibility.
I have found these related issues/pull requests
N/A
Description
As tests need a user with elevated permissions, the docs mention
superuser. I would like to be able to specify a dedicated test user to maintain the 'principle of least privilege' for existing production and development users.I was hoping
async fn(PoolOptions<DB>, impl ConnectOptions<DB>) -> Retwould satisfy this request by granting access toConnectOptionsbefore the pool is created, but I couldn't get it to work, and it seemed to fail before the body of the function is run in my partial testing.If this is the right course of action and the resulting failures were simply something on my end, do let me know, and I'll investigate further. I wanted to check first before spending more time fighting the tests.
Prefered solution
DATABASE_URL_TESToverwrite withDATABASE_URLas a fallback, so as not to introduce breaking changes.Alternatively, a change to
async fn(PoolOptions<DB>, impl ConnectOptions<DB>) -> Retto allow alternative connection, assuming my failure wasn't at the fault of my codebase.Is this a breaking change? Why or why not?
No, current behaviour can be maintained if desired, and if the macro was updated regarding the function signature, then populating the arguments with the existing DB connection would also maintain existing behaviour while adding more flexibility.