Closed EtienneDx closed 8 months ago
Looking further into the possibilities, a possible rust orm is diesel. For further coherence between the projects, the structures of the database can be defined directly in rust, while the apis can be defined in protobuf to allow the typescript project to know what it queries.
While it would be possible to define the database directly in protobuf, it would also expose some data or schema that should remain confidential, thus I think we should maintain it separate, even though it means having some redundancy between protobuf and rust.
Regarding the discussed status from CI, I think we need to add another entity:
enum Status {
Success,
Pending,
Cancelled,
Failed(String),
}
struct CiRun {
repository: Repository,
commit: String,
status: Status,
}
yes and add email to user!
Is that what we want?
Overall looks like it yeah, things might somehow evolve later on but for now looks good
Can we change the names of Group and Group Student to make it clearer? I am not sure to see the difference... Moreover, we should add an image somewhere in there for profile pictures! Three options:
Are the creation dates of each entry managed automatically? This will be useful for the displays. How will the content of a repo be managed? commits, folders, etc.
Repos are managed via file system directly (git bare repos), so the database only holds the metadata. This means a s**t-ton of weird APIs to get the data. Hopefully there'll be an easy and clean way to do it but most likely it'll be a pain ^^'
Regarding the images, I think we should go with an optional url field. In case the field is empty, we can use Jdenticon or another lib to generate default ones on the go. Long term we'll add image uploading to an s3 bucket.
For the date stuff, I guess we insert it within the APIs?
Can we change the names of Group and Group Student to make it clearer? I am not sure to see the difference... Moreover, we should add an image somewhere in there for profile pictures! Three options:
- have a field for a png for each user (heavy weaponry option)
- have a table with default images and the users reference the one they want (possibility to have quite a few images, but difficult for custom ones)
- same thing but have the default images stored in the frontend (it is better to limit the number of images for performance issues, impossible to have custom ones)
Database is ready, is there some functions we need to implement?
TODO: Unit tests with independant test database (CRUD + JOIN)
I have a test environnent and a first test but i can't connect to the database "Cannot connect to postgres database.: BadConnection("connection to server at \"localhost\" (::1), port 5432 failed: FATAL: authentification par mot de passe �chou�e pour l'utilisateur � admin_user �\n")". I don't know why because password is right so i might need some help with that.
Taking over with #29
Closed with #29
Add a PostgreSQL database connection to the gmt-server.
The connection should use an ORM to facilitate the access to the data.
Here's an overview of the data, which should still be refined:
This database will be reused by multiple services, and should therefore live in a separate crate. This crate will then be included in the target services.