4 Commits

Include renames

Author	SHA1	Message	Date
4 people	f5ce288ea5	feat(domain): define user repositories (#11059) ... This pull request introduces a new set of domain models and repositories for managing users within the new v3 structure. The goal is to establish a clean, robust, and extensible foundation for user management. ### Summary This PR accomplishes the following: - **Polymorphic User Model**: Introduces a `User` model in user.go that can represent either a `Human` or a `Machine` user. This provides a unified way to handle different user types while allowing for specific attributes and logic for each. - **Repository Pattern**: Implements the repository pattern for accessing and manipulating user data. This decouples the business logic from the data storage implementation. The main repository interfaces (`UserRepository`, `HumanUserRepository`, `MachineUserRepository`) are now defined in `backend/v3/domain/user_repository.go`. - **Comprehensive User Models**: The user.go file now also defines the domain models for associated user data, including `UserMetadata`, `IdentityProviderLink`, `Passkey`, `PersonalAccessToken`, and `MachineKey`. - **Generic Verification and Check System**: Introduces verification.go and check.go to provide a standardized way of handling various verification flows (e.g., email verification, OTP checks). - **Generated Code**: Adds new generated files for enums (`humangender_enumer.go`, `machinekeytype_enumer.go`, `passkeytype_enumer.go`, `personalaccesstokentype_enumer.go`, `userstate_enumer.go`, `usertype_enumer.go`) and mocks for the new repositories. - **Session Domain Refactoring**: Updates the session domain (`backend/v3/domain/session*.go`) to align with the new user model structure. This foundational work paves the way for migrating user management logic to the new `v3` backend, with a more maintainable and testable architecture. part of #10224 --------- Co-authored-by: Copilot <[email protected]> Co-authored-by: Marco A. <[email protected]>	2025-11-25 11:54:32 +01:00
3 people	f230cf0fb5	refactor(rt): add primary key columns to repo interfaces (#10843) ... # Which Problems Are Solved Relational table's primary keys are part of the SQL table definition. However, by abstraction through the repository interfaces callers (service layer) have no clear understanding of the primary key definion. This might lead to confusion during implementation: - The repository makes a sanity check on required conditions before query execution and returns an error if the condition was not met. - When a Get method is executed, an error is returned if not exactly one row is found. Get replaces the legacy GetXxxByID methods we have on projections. However, a list of flexible conditions can be passed. - Operations like UPDATE and DELETE should often only affect a single row, identified by the primary key. If the primary key conditions are missing an error is returned. Because there is no "type safety" enforced here, the errors are returned during runtime. When all possible combinations of API arguments are not properly tested such errors are actually bugs in the experience of the end-user. (The API should do it's own input validation, but a programmer's error is easily made). # How the Problems Are Solved Add `PrimaryKeyColumns` and `PrimaryKeyCondition` to existing repository intefaces. # Additional Changes - Where reducers already used repositories, the PrimaryKeyConditions are used where possible. # Additional Context - Part of https://github.com/zitadel/zitadel/wiki/Decision-Log#expose-primary-key-definition-in-repository-interfaces --------- Co-authored-by: Marco A. <[email protected]>	2025-10-22 08:40:21 +00:00
SilvanandGitHub	cccfc816f6	refactor: database interaction and error handling (#10762) ... This pull request introduces a significant refactoring of the database interaction layer, focusing on improving explicitness, transactional control, and error handling. The core change is the removal of the stateful `QueryExecutor` from repository instances. Instead, it is now passed as an argument to each method that interacts with the database. This change makes transaction management more explicit and flexible, as the same repository instance can be used with a database pool or a specific transaction without needing to be re-instantiated. ### Key Changes - **Explicit `QueryExecutor` Passing:** - All repository methods (`Get`, `List`, `Create`, `Update`, `Delete`, etc.) in `InstanceRepository`, `OrganizationRepository`, `UserRepository`, and their sub-repositories now require a `database.QueryExecutor` (e.g., a `*pgxpool.Pool` or `pgx.Tx`) as the first argument. - Repository constructors no longer accept a `QueryExecutor`. For example, `repository.InstanceRepository(pool)` is now `repository.InstanceRepository()`. - **Enhanced Error Handling:** - A new `database.MissingConditionError` is introduced to enforce required query conditions, such as ensuring an `instance_id` is always present in `UPDATE` and `DELETE` operations. - The database error wrapper in the `postgres` package now correctly identifies and wraps `pgx.ErrTooManyRows` and similar errors from the `scany` library into a `database.MultipleRowsFoundError`. - **Improved Database Conditions:** - The `database.Condition` interface now includes a `ContainsColumn(Column) bool` method. This allows for runtime checks to ensure that critical filters (like `instance_id`) are included in a query, preventing accidental cross-tenant data modification. - A new `database.Exists()` condition has been added to support `EXISTS` subqueries, enabling more complex filtering logic, such as finding an organization that has a specific domain. - **Repository and Interface Refactoring:** - The method for loading related entities (e.g., domains for an organization) has been changed from a boolean flag (`Domains(true)`) to a more explicit, chainable method (`LoadDomains()`). This returns a new repository instance configured to load the sub-resource, promoting immutability. - The custom `OrgIdentifierCondition` has been removed in favor of using the standard `database.Condition` interface, simplifying the API. - **Code Cleanup and Test Updates:** - Unnecessary struct embeddings and metadata have been removed. - All integration and repository tests have been updated to reflect the new method signatures, passing the database pool or transaction object explicitly. - New tests have been added to cover the new `ExistsDomain` functionality and other enhancements. These changes make the data access layer more robust, predictable, and easier to work with, especially in the context of database transactions.	2025-09-24 10:12:31 +00:00
6 people	61cab8878e	feat(backend): state persisted objects (#9870) ... This PR initiates the rework of Zitadel's backend to state-persisted objects. This change is a step towards a more scalable and maintainable architecture. ## Changes * **New `/backend/v3` package**: A new package structure has been introduced to house the reworked backend logic. This includes: * `domain`: Contains the core business logic, commands, and repository interfaces. * `storage`: Implements the repository interfaces for database interactions with new transactional tables. * `telemetry`: Provides logging and tracing capabilities. * **Transactional Tables**: New database tables have been defined for `instances`, `instance_domains`, `organizations`, and `org_domains`. * **Projections**: New projections have been created to populate the new relational tables from the existing event store, ensuring data consistency during the migration. * **Repositories**: New repositories provide an abstraction layer for accessing and manipulating the data in the new tables. * **Setup**: A new setup step for `TransactionalTables` has been added to manage the database migrations for the new tables. This PR lays the foundation for future work to fully transition to state-persisted objects for these components, which will improve performance and simplify data access patterns. This PR initiates the rework of ZITADEL's backend to state-persisted objects. This is a foundational step towards a new architecture that will improve performance and maintainability. The following objects are migrated from event-sourced aggregates to state-persisted objects: * Instances * incl. Domains * Orgs * incl. Domains The structure of the new backend implementation follows the software architecture defined in this [wiki page](https://github.com/zitadel/zitadel/wiki/Software-Architecturel). This PR includes: * The initial implementation of the new transactional repositories for the objects listed above. * Projections to populate the new relational tables from the existing event store. * Adjustments to the build and test process to accommodate the new backend structure. This is a work in progress and further changes will be made to complete the migration. --------- Co-authored-by: Copilot <[email protected]> Co-authored-by: Iraq Jaber <[email protected]> Co-authored-by: Iraq <[email protected]> Co-authored-by: Tim Möhlmann <[email protected]>	2025-09-05 09:54:34 +01:00