refacto(continuous_screening): use unique table to store monitored ob…

[OrriMandarin]

This pull request refactors the way internal tables for continuous screening monitored objects are created and managed. Instead of creating separate tables per object type, the system now uses a single table (_monitored_objects) with an object_type column to distinguish between different types. This simplifies schema management and improves query efficiency. The changes also update related repository and usecase logic, as well as tests and mocks, to align with the new table structure.

Database schema and repository changes:

• Replaced per-object-type internal tables with a single table (_monitored_objects) that includes a new object_type column, and updated unique and regular indexes to use this column. [1] [2]
• Updated repository methods (CreateInternalContinuousScreeningTable, InsertContinuousScreeningObject, GetMonitoredObject, ListMonitoredObjectsByObjectIds) to use the unified table and accept object_type as a parameter instead of table name. [1] [2] [3] [4] [5]

Model and DTO changes:

• Added ObjectType field to ContinuousScreeningMonitoredObject model and its corresponding DB representation and adapters. [1] [2] [3]

Usecase logic changes:

• Refactored usecase logic to create the internal monitored objects table once per organization, rather than per object type, and updated object type validation logic. [1] [2] [3] [4] [5]

Test and mock updates:

• Updated tests and mocks to match the new method signatures and table creation logic, removing references to per-object-type table creation. [1] [2] [3] [4] [5] [6] [7] [8]

[linear]

MAR-1372 Refacto monitored table to have an unique table for all object type

[Copilot]

Pull request overview

This pull request refactors the continuous screening feature to use a unified table structure for storing monitored objects. Instead of creating separate tables for each object type (e.g., _monitored_objects_transactions, _monitored_objects_customers), the system now uses a single _monitored_objects table with an object_type column to distinguish between different types. This simplifies schema management and improves maintainability.

Key changes include:

• Consolidated table schema with a new object_type column and updated indexes
• Simplified table creation logic to run once per organization instead of per object type
• Updated repository methods to accept objectType parameter instead of tableName

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
repositories/continuous_screening_client_repository.go	Refactored table creation to use a single unified table with object_type column; updated insert, get, and list methods to work with the new schema
repositories/dbmodels/db_continuous_screening.go	Added ObjectType field to DBContinuousScreeningMonitoredObject struct and updated adapter function
models/continuous_screening.go	Added ObjectType field to ContinuousScreeningMonitoredObject model
usecases/continuous_screening/usecase.go	Updated interface definition to remove tableName parameter and use objectType instead
usecases/continuous_screening/org_config.go	Simplified table creation logic to run once per organization; renamed processObjectTypes to checkDataModelConfiguration to reflect its new purpose of validation only
usecases/continuous_screening/org_config_test.go	Updated test mocks to match new method signatures with simplified table creation calls
mocks/continuous_screening_repository.go	Updated CreateInternalContinuousScreeningTable mock signature to remove tableName parameter

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[Pascal-Delange]

👍