Implementation logical database scheme

[brentjan]

First draft of the implementation of the logical database scheme. There are some changes needed to the presented database scheme in #2 .

Things yet to do:

• Write code that closes and saves the database in a clean way when the server is manually shut down
• Have some more concise logging when initializing/shutting down the database
• See if there's a way to have the database username, password, ... in a seperate file instead of hardcoded constants
• Test insertion and querying

[brentjan]

Insight: the way i initialize the database in index.ts is not how the Clean architecture works. We'll need to define interfaces for setting up the database connection and implement it for the PostgreSQL database.

[bramcomyn]

First thing that comes to my mind is: why does he want to push to main already? 😉 Let's start by changing that into development :)

[bramcomyn]

I approve these changes, with the small detail I commented on. See below:

[bramcomyn]

Wouldn't it be better to rename this to Invite? I know this might be a bit of a detail, but I feel like that name would suit better the purpose of this entity

[brieromb]

Zou de naam voor deze tabel niet beter iets zoals PendingJoinRequests zijn? Aangezien het nu eigenlijk de zender van de invite is die de geïnviteerde moet accepteren, en niet omgekeerd zoals je zou verwachten bij invites.

[brieromb]

forename veld naar first_name hernoemen?

[brieromb]

Goed gedaan @brentjan! Ik heb nog 2 kleine opmerkingen geplaatst, maar voor de rest ziet dit er echt goed uit.

[brentjan]

Should be able to be null if there isn't a thread yet? Same for answer.

Maybe with:

@OneToOne(() => AssignmentAnswer, { nullable: true })

But this might not be supported by PostgreSQL

[brentjan]

Applied the comments from the reviews and also did some of the small todo's mentioned above.

Big change: the classes i defined previously are now in /backend/src/infrastructure/database/data/data_models. These classes are specific for TypeORM and should not be used in any business logic!

The clean-architecture way of working says we need to define general data entities (example in backend/src/core/entities), these are then used in business logic.

Ofcourse when we write queries with TypeORM we will need to map the TypeORM data models to entities as said in this article (under "Mapping").

Can @thomasdejaeghere and @bramcomyn check that this is indeed the case?
Can @brieromb help me implement these entities?

[bramcomyn]

I would change the name of this Interface to ITeacher to avoid long class names in the future.

[thomasdejaeghere]

Applied the comments from the reviews and also did some of the small todo's mentioned above.

Big change: the classes i defined previously are now in /backend/src/infrastructure/database/data/data_models. These classes are specific for TypeORM and should not be used in any business logic!

The clean-architecture way of working says we need to define general data entities (example in backend/src/core/entities), these are then used in business logic.

Ofcourse when we write queries with TypeORM we will need to map the TypeORM data models to entities as said in this article (under "Mapping").

Can @thomasdejaeghere and @bramcomyn check that this is indeed the case? Can @brieromb help me implement these entities?

This is indeed true, In my last push to branch 11 I already set up the needed files for the Student entity, connection with the database then needs to implemented in UserRepositoryImpl.ts in /backend/src/infrastructure/repositories. Code looks good! I will merge this branch into dev.