feat: ability to create a project #9
@@ -22,17 +22,18 @@ pub(crate) async fn create_project(
|
|||||||
|
|
|||||||
.validate()
|
.validate()
|
||||||
.map_err::<ErrorVec<ProjectCreateError>, _>(|errors| errors.into())?;
|
.map_err::<ErrorVec<ProjectCreateError>, _>(|errors| errors.into())?;
|
||||||
|
|
||||||
let mut connection =
|
let mut connection = establish_database_connection()
|
||||||
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
|
|||||||
establish_database_connection().or::<ErrorVec<ProjectCreateError>>(Err(vec![
|
.map_err::<ErrorVec<ProjectCreateError>, _>(
|
||||||
|
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
|
|||||||
ProjectCreateError::Error(Error::ServerInternal),
|
|_| vec![ProjectCreateError::Error(Error::ServerInternal), ].into()
|
||||||
|
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
|
|||||||
]
|
)?;
|
||||||
|
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
|
|||||||
.into()))?;
|
|
||||||
|
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
|
|||||||
|
|
||||||
let new_project = diesel::insert_into(projects::table)
|
let new_project = diesel::insert_into(projects::table)
|
||||||
.values(&new_project)
|
.values(&new_project)
|
||||||
.returning(Project::as_returning())
|
.returning(Project::as_returning())
|
||||||
.get_result(&mut connection)
|
.get_result(&mut connection)
|
||||||
.expect("error saving a new project");
|
.map_err::<ErrorVec<ProjectCreateError>, _>(
|
||||||
|
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
|
|||||||
|
|_| vec![ProjectCreateError::Error(Error::ServerInternal), ].into()
|
||||||
|
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
|
|||||||
|
)?;
|
||||||
|
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
|
|||||||
|
|
||||||
Ok(new_project)
|
Ok(new_project)
|
||||||
}
|
}
|
||||||
|
|||||||
|
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Ensure proper error handling for database connections. The **Ensure proper error handling for database connections.**
The `establish_database_connection` function call should handle potential errors instead of assuming a successful connection. Consider using `Result` to propagate errors.
```rust
let connection = establish_database_connection().map_err(|e| {
eprintln!("Failed to connect to the database: {}", e);
ServerFnError::from(e)
})?;
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Avoid using Using **Avoid using `expect` for error handling in production code.**
Using `expect` can cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.
```rust
.get_result(&mut connection)
.map_err(|e| {
eprintln!("Error saving a new project: {}", e);
ServerFnError::from(e)
})
```
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
Consider removing the The **Consider removing the `testing` function.**
The `testing` function is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.
<!-- This is an auto-generated comment by CodeRabbit -->
|
|||||||
Ensure proper error handling for database connections.
The
establish_database_connectionfunction call should handle potential errors instead of assuming a successful connection. Consider usingResultto propagate errors.Avoid using
expectfor error handling in production code.Using
expectcan cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.Ensure proper error handling for database connections.
The
establish_database_connectionfunction call should handle potential errors instead of assuming a successful connection. Consider usingResultto propagate errors.Avoid using
expectfor error handling in production code.Using
expectcan cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.Avoid using
expectfor error handling in production code.Using
expectcan cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.Avoid using
expectfor error handling in production code.Using
expectcan cause the program to panic on errors. Consider using proper error handling to return a meaningful error message.Consider removing the
testingfunction.The
testingfunction is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.Consider removing the
testingfunction.The
testingfunction is a simple utility that adds 1 to the input. If it's not used in production, consider removing it to keep the codebase clean.