init db and table, check health #55
Conversation
|
👋 Thanks for assigning @tnull as a reviewer! |
rust/impls/Cargo.toml
Outdated
| @@ -10,6 +10,7 @@ chrono = "0.4.38" | |||
| tokio-postgres = { version = "0.7.12", features = ["with-chrono-0_4"] } | |||
| bb8-postgres = "0.7" | |||
| bytes = "1.4.0" | |||
| tokio = { version = "1.38.0", default-features = false } | |||
There was a problem hiding this comment.
I think we need the time feature?
| @@ -46,17 +62,103 @@ pub struct PostgresBackendImpl { | |||
| pool: Pool<PostgresConnectionManager<NoTls>>, | |||
| } | |||
|
|
|||
| async fn initialize_vss_database(postgres_endpoint: &str, db_name: &str) -> Result<(), Error> { | |||
| let postgres_dsn = format!("{}/{}", postgres_endpoint, "postgres"); | |||
| let (client, connection) = tokio_postgres::connect(&postgres_dsn, NoTls).await | |||
There was a problem hiding this comment.
Hmm, do we want to expose a way for the user to configure their connection, e.g. to enable TLS?
There was a problem hiding this comment.
Yes certainly, though may be out of scope for this PR.
| let postgres_dsn = format!("{}/{}", postgres_endpoint, "postgres"); | ||
| let (client, connection) = tokio_postgres::connect(&postgres_dsn, NoTls).await | ||
| .map_err(|e| Error::new(ErrorKind::Other, format!("Connection error: {}", e)))?; | ||
| // Connection must be driven on separate task, will be dropped on client dropped |
There was a problem hiding this comment.
Why does it need to be driven on separate task? Should we still keep track of this connection handle somewhere? Rather than just printing once and giving up, should we handle the error and/or add a loop to retry the connection?
There was a problem hiding this comment.
Why does it need to be driven on a separate task?
From the docs:
A connection to a PostgreSQL database.
This is one half of what is returned when a new connection is established. It performs the actual IO with the server, and should generally be spawned off onto an executor to run in the background.
Connection implements Future, and only resolves when the connection is closed, either because a fatal error has occurred, or because its associated Client has dropped and all outstanding work has completed.
Is that satisfactory to you ?
Should we still keep track of this connection handle somewhere?
The connection future will only resolve when I drop the client, so not sure what I would do with the associated JoinHandle ?
Rather than just printing once and giving up, should we handle the error and/or add a loop to retry the connection?
Since this is part of the startup sequence, I was leaning towards having very little error handling, and failing fast and early. This lets the user know that something is not right.
Then once we are running, do all that we can to keep the show going.
rust/server/src/main.rs
Outdated
| std::process::exit(1); | ||
| } | ||
| let init_db = args.contains(&String::from("--init-db")); |
There was a problem hiding this comment.
If you cast to slice directly, why allocate a String first?
There was a problem hiding this comment.
contains on a Vec<String> wants a &String specifically.
But we can replace this with args.iter().any(|arg| arg == "--init-db")
|
A possible todo I thought of: right now our |
Soft-push, seems to be working !
for now check health is just used internally to test the database on startup.