docs(comp.backend): ADR - Enable filtering for component instance without support group or service

[dustindemmerle]

Description

Our current database schema enforces having a service id for each component instance, which could potentially present problems if we decide to change this requirement in the future. The relationship between component instances, services, and support groups is complex, with a many-to-many relationship between service and support group. This setup may lead to challenges in managing and maintaining the data.

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation Update
• 🎨 Style
• 🧑‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🤖 Build
• 🔁 CI
• 📦 Chore (Release)
• ⏩ Revert

Related Tickets & Documents

• Fixes feat(comp.backend): Enable filtering for component instance without support group or service #180

Added tests?

• 👍 yes
• 🙅 no, because they aren't needed
• 🙋 no, because I need help
• Separate ticket for tests # (issue/pr)

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Added to documentation?

• 📜 README.md
• 🤝 Documentation pages updated
• 🙅 no documentation needed
• (if applicable) generated OpenAPI docs for CRD changes

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[drochow]

Doesnt it make most sense to:

Create a "system" support group & service "unwkown" with the DB init and actually set default values on the DB for support group and service.

We may need to check if that would work.

[MR2011]

Doesnt it make most sense to:

Create a "system" support group & service "unwkown" with the DB init and actually set default values on the DB for support group and service.

We may need to check if that would work.

Support Group and Service are a many to many relationship. So we have to use a DB trigger to insert a default entry in the join table. Once we assign a Service to a real Support Group, we need a trigger, that will remove the default assignment again.

[drochow]

Support Group and Service are a many to many relationship. So we have to use a DB trigger to insert a default entry in the join table. Once we assign a Service to a real Support Group, we need a trigger, that will remove the default assignment again.

Well I disagree, I did not talk about the relation between Support Group and Service but rather having a default Support Group with a default relation to a default Service. This relationship actually never changes.

What changes potentially is the service a component instance is attached to. For this, we define a default value for the created default service.

[drochow]

This:

insert into heureka.Service (service_name) values ('Unkown');
insert into heureka.SupportGroup (supportgroup_name) values ('Unkown');
insert into heureka.SupportGroupService (supportgroupservice_service_id, supportgroupservice_support_group_id) values (1, 1);

create table if not exists ComponentInstance
(
    componentinstance_id                   int unsigned auto_increment
        primary key,
    componentinstance_ccrn                 varchar(2048)                         not null,
    componentinstance_count                int       default 0                   not null,
    componentinstance_component_version_id int unsigned                          not null,
    componentinstance_service_id           int unsigned default 1                not null,
    componentinstance_created_at           timestamp default current_timestamp() not null,
    componentinstance_deleted_at           timestamp                             null,
    componentinstance_updated_at           timestamp default current_timestamp() not null on update current_timestamp(),
    constraint id_UNIQUE
        unique (componentinstance_id),
    constraint name_service_unique
        unique (componentinstance_ccrn, componentinstance_service_id) using hash,
    constraint fk_component_instance_component_version
        foreign key (componentinstance_component_version_id) references ComponentVersion (componentversion_id)
            on update cascade,
    constraint fk_component_instance_service
        foreign key (componentinstance_service_id) references Service (service_id)
            on update cascade
);

[MR2011]

And Services have a default relationship to that SupportGroup too? So we can detect Services without SupportGroup

[drochow]

Yes that would make sense to me

[drochow]

Agreement?

[MR2011]

I agree with having a Unknown Service with an Unknown SupportGroup that we can attach to a ComponentInstance, that does not have a service.

But what about the Service and Support Group scenario?
If I create a new Service, we add the default Unknown SupportGroup to it. Now I add the SupportGroup X to the Service. What do we do with the relation to the Unknown SupportGroup?

[drochow]

If I create a new Service, we add the default Unknown SupportGroup to it. Now I add the SupportGroup X to the Service. What do we do with the relation to the Unknown SupportGroup?

I agree that's business logic we need to add. I would add an event handler that is checking for that and removing the relationship if any other group is present.

[drochow]

We agreed that the logic should be in the app layer even though it would be simpler in the DB layer