-
Notifications
You must be signed in to change notification settings - Fork 2
Bump dependencies #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Initiating social contact... We're scanning your PR for issues. Stand by for comments. Lots of love, |
|
@rover-app review |
|
Hey @renatillas! This repo doesn't seem to be connected to Rover. Please double check via the Rover platform! Lots of love, |
src/pevensie/postgres.gleam
Outdated
| driver: Postgres(config, None), | ||
| connect:, | ||
| disconnect:, | ||
| disconnect: fn(driver) { Ok(driver) }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how I feel about this. Is there not a way to disconnect anymore? Can we not stop the child process?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not anymore. The connect and disconnect functions of pgo have been removed: https://github.com/lpil/pog/blob/main/CHANGELOG.md#v400---2025-07-07. I can try by as you say, stopping the child process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests for pog seem to use process.send_exit to shut down the connection pool. I wonder if we should implement something similar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ignore this - I see you've implemented that
| /// } | ||
| /// ``` | ||
| pub fn default_config() -> PostgresConfig { | ||
| pub fn default_config(pool_name: process.Name(pog.Message)) -> PostgresConfig { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change needs an update to the readme, please!
src/pevensie/postgres.gleam
Outdated
| ) | ||
| let conn = pog.connect(config) | ||
| let conn = pog.supervised(config) | ||
|
|
||
| // Start supervision tree | ||
| use _ <- result.try( | ||
| supervisor.new(supervisor.OneForOne) | ||
| |> supervisor.add(conn) | ||
| |> supervisor.start() | ||
| |> result.replace_error( | ||
| snag.Snag(issue: "Failed to start Postgres connection", cause: [ | ||
| "failed to start connection", | ||
| ]), | ||
| ), | ||
| ) | ||
|
|
||
| let conn = pog.named_connection(pool_name) | ||
| let transaction_result = | ||
| pog.transaction(conn, fn(tx) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we need a supervised connection here. The rest of the CLI isn't running in a supervision tree, so I'm not sure how much benefit we get from it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah after understanding better how supervision works, you are right. It does not make sense to add a supervision tree on a CLI tool with short lived processes.
|
Also, would you mind bumping the Gleam version in the gleam.toml and CI? |
| let pog_config = postgres_config_to_pog_config(config) | ||
| let conn = pog.named_connection(pog_config.pool_name) | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're going to run into some issues here, on second thought. The disconnect method shuts down a connection pool, but the connect method no longer creates one. That makes this upgrade a breaking change. I'm not sure how to handle this, as ideally the connection pool should be supervised, but we can't start and stop that on demand.
Do you have any ideas here?
As a bit of extra context, I'll be working on Pevensie V2 soon, which will only support Postgres (and therefore can rely on users passing in a Postgres connection directly). I'm wondering if we should just accept that it's going to be a breaking change and adopt that model, with the connect and disconnect methods effectively becoming no-ops in this case. It's not a great solution, but it would allow us to get something working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should leave the connect and disconnect methods behind, as you said. It's a breaking change but migrations shouldn't be hard.
This Draft aims to bump the dependencies of pog, gleam_otp, gleam_erlang and has the addition of gleam_time as it's used by pog now.