Skip to content

Conversation

@momentary-lapse
Copy link
Contributor

Addresses: #4979

.await;

// TODO make compatible with ActualDbPool
db_pool.pull_immutable().await
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created this WIP PR to share the progress and the issue I'm stuck with currently. The crate I use operates with its own structure wrapping connection pools: code
And we have our own ActualDbPool. They are kinda same, but it's not obvious for me how to correctly convert one to another.
I had an idea to make ActualDbPool a enum with two possible values: RegularPool and ReusablePool, but stuck on trying to adapt stuff like LemmyContext, which also requires pool struct to be clone-able (and ReusablePool is not). And it seems a lot of changes to the main codebase for purely test changes.
Do you folks have any ideas how to manage that? Or should I stick to the initial plan without using this library?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our ActualDbPool is just a type alias for deadpool Pool<AsyncPgConnection>.

Their crate should be able to work with deadpool pools, but I'm not familiar with how to plug that into their crate... you'll have to ask them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I see. I returned to this issue today after a week of a break. I'm in contact with the db-pool author and they're helping to understand a lot of moments and really willing to collaborate, so i think we'll make this work.

I'd like to clarify one moment: do we want build_db_pool_for_tests to return still ActualDbPool? db-pool has its own wrapper ReusableConnectionPool which works like a deadpool Pool, but a bit different and needs adaptation. And it might be easier to adapt tests for working with ReusableConnectionPool than converting ReusableConnectionPool to ActualDbPool

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The return type of build_db_pool_for_tests may be changed. Also, a DbPool variant may be added if needed.

#[derive(Clone)]
pub struct LemmyContext {
pool: ActualDbPool,
pool: ContextPool,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the moment which currently blocks me, and i think it's better to consult with you again. LemmyContext structure must be cloneable, therefore all the fields, therefore the pool. But unfortunately, reusable pool from db-pool crate is not, and i don't have access to its fields to implement the trait here.
But before asking db-pool developer, i'd like to be sure we really need this pool cloning stuff, especially for the tests. Cloning the pool seems a bit strange to me, but i may miss something. I'm looking at the code now, but maybe you folks already have some insights on this

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrap it in Arc for now.

@momentary-lapse
Copy link
Contributor Author

Update: I'm working on the topic; cannot devote much time for it, but it slowly going forward, and i keep the code in the branch up-to-date. I connected db-pool crate to our tests, and reworked most of them. Currently have a runtime error, planning to look at it and fix this week.
After this, what is left is to change a few tests which are using build_db_pool function.

@momentary-lapse
Copy link
Contributor Author

Hey! I've a question about the replaceable schema — found out it's the reason tests are failing in the branch: the tests are being run in restricted privilege mode, and have no access to the r schema. I can do some workaround, but would like to ask about motivation for making that replaceable schema — for me it seems a bit unsafe, since there in theory might be migrations which require changes in these files. Also, am I right that the triggers and utils are separated into another schema because it's just easier to clean them up at once?

@dessalines
Copy link
Member

Yes I believe the main reason is so that they're easier to clean up.

for me it seems a bit unsafe, since there in theory might be migrations which require changes in these files.

Everything in the r schema should only contain triggers and functions used at runtime, not by any migrations. They're only run once, at the end of all the migrations. The main reason to do it like this, is because it was extremely cumbersome to tweak every trigger and function within the migrations, copying and pasting every time, rather than doing tweaks to a simple sql file.

the tests are being run in restricted privilege mode

Is this a limitation of the db-pool library? Because regular cargo tests can already run the build_db_pool_for_tests function which runs the replaceable schema.

@momentary-lapse
Copy link
Contributor Author

Is this a limitation of the db-pool library?

Yep, it's designed the way you have privileged connection pool to prepare dbs and do migrations, and restricted connection pool to run tests. And the latest can only access public schema of each db. So, the library would work out of the box if we had these runtime functions in the same schema

@dessalines
Copy link
Member

Maybe its just a matter of running GRANT for the current lemmy user on that schema, as part of the setup?

https://stackoverflow.com/questions/17338621/what-does-grant-usage-on-schema-do-exactly

cc @dullbananas

@momentary-lapse
Copy link
Contributor Author

momentary-lapse commented Aug 25, 2025

that's an option i'm thinking about. but unfortunately it has certain caveats.
what does the db-pool library do, it prepares multiple databases with names like:

  • db-pool-uuid1
  • db-pool-uuid2
    etc.
    and it creates a separate role with restricted rights for each db named exactly as this db. so to grant permissions after the migrations are done here, i need to know the current db name, which is afaik impossible to retrieve from the connection only.

however, i can change it in a fork, so it will use the same role for all the restricted connections (e.g. _db_pool_test_role). then we can grant access to schema r for that user after migrations are done

@dullbananas
Copy link
Collaborator

Maybe its just a matter of running GRANT for the current lemmy user on that schema, as part of the setup?

Maybe. The problem is almost certainly caused by something being different between the "public" schema and the "r" schema. Otherwise migrations would have failed before replaceable_schema runs.

@momentary-lapse
Copy link
Contributor Author

There's logic in the db-pool library which grants permission to restricted user fro public schema assuming it's the only one tests will deal with.
Anyway, i reported that, and we agreed he'll take time to think how to change that. So, we're in touch. And if he decides to keep the logic, i have some ideas for a workaround for our case


pg_ctl stop --silent
rm -rf $PGDATA
docker-compose -f docker/docker-compose-test.yml down
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should remain unchanged so that it uses Postgres from a local folder instead of starting a Docker container because starting a Docker container requires root. It is possible to allow docker commands without root, but then every application can execute docker commands and easily get root permissions.

This will require changes to db_pool::PrivilegedPostgresConfig. Honestly that file is unnecessary because it takes the parts from a db url and then converts it back to a db url. So its best to remove PrivilegedPostgresConfig entirely, and change the first param of DieselAsyncPostgresBackend::new from privileged_config: PrivilegedPostgresConfig to db_url: Url. The logic in privileged_database_connection_url() and restricted_database_connection_url() can be handled by Url.set_password() etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I agree. I just skipped this issue in order to focus on the main part for now

OnceCell::const_new();
let db_pool = POOL
.get_or_init(|| async {
let conn_string = SETTINGS.get_database_url();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to call SETTINGS.get_database_url_with_options()?; here and then pass that directly into DieselAsyncPostgresBackend::new() (as explained in my other comment). Because the db url includes the option lemmy.protocol_and_hostname. At the moment triggers are failing with unrecognized configuration parameter "lemmy.protocol_and_hostname" because that option is missing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks much, was about to ask about that. I really don't want to give up on that feature. Didn't have time/mental capacity to work on it consistently, but now it's better. Recently made a workaround for db-pool permissions, which seems to work, so there's a slow progress. And trying to keep it up with regular lemmy updates

db-pool = { git = "https://github.com/momentary-lapse/db-pool.git", branch = "edition2021-test-superuser", features = [
"diesel-async-postgres",
"diesel-async-deadpool",
] }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be a dev dependency. But dont worry about it for now, what matters is to get the parallel tests working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants