Fix ObjectType casing and conflict between Relation and RelationMetadata #9849
Conversation
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR Summary
This PR standardizes GraphQL type naming conventions across the codebase by fixing casing inconsistencies and resolving naming conflicts between 'Relation' and 'RelationMetadata'.
- Renamed
RelationtoRelationMetadatain GraphQL schema and updated related mutations (e.g.,createOneRelation→createOneRelationMetadata) - Removed explicit name parameters from
@ObjectTypedecorators across server entities to follow NestJS best practices - Updated filter type names from lowercase to PascalCase (e.g.,
objectFilter→ObjectFilter) in GraphQL queries - Fixed casing in metadata DTOs by changing lowercase type names to proper PascalCase (e.g.,
field→Field,object→Object) - Standardized GraphQL type definitions in generated code to use consistent PascalCase naming
31 file(s) reviewed, 1 comment(s)
Edit PR Review Bot Settings | Greptile
|
@FelixMalfait We need to be careful with renaming as it's a breaking change, I don't think people are directly using our GraphQL API for now. But in case it happens all the apps that doesn't re-generate the front-end schema will brake. |
|
@magrinj yes good point! Would you mind checking and adjusting the PR if you feel that the renaming is not the good one? I don't have much context on relations |
Updated GraphQL typings by removing unnecessary FeatureFlag type usage and aligning the `formatRelationMetadataInput` input structure. Simplified and reformatted mock data for better readability and maintainability.
|
I fixed the typing. What's the decision about the breaking change @magrinj? |
Update __typename literal values to use proper casing (e.g., 'Object', 'Field', 'Index', 'IndexField') for consistency with expected schema definitions. This ensures compatibility and prevents potential issues with type validation in the application.
|
Hold before merge, not sure it's the right fix to me |
|
maybe it's the right fix actually, I leave it to @magrinj |
Renamed `relation` to `relationMetadata` in mock variables to ensure consistency with updated schema expectations. This change aligns the mocked data structure with the actual API requirements.
| @@ -17,7 +17,7 @@ import { FeatureFlagKey } from 'src/engine/core-modules/feature-flag/enums/featu | |||
| import { Workspace } from 'src/engine/core-modules/workspace/workspace.entity'; | |||
|
|
|||
| @Entity({ name: 'featureFlag', schema: 'core' }) | |||
| @ObjectType('FeatureFlag') | |||
| @ObjectType() | |||
There was a problem hiding this comment.
@FelixMalfait @AMoreaux Not sure about this one FeatureFlagEntity name will be used instead of FeatureFlag.
I don't think we're directly using for now the entity type as a graphQL DTO, but it's better to keep the name for that one
There was a problem hiding this comment.
Or maybe we should just rename the class FeatureFlagEntity to FeatureFlag if we don't have any conflict with other types.
There was a problem hiding this comment.
I prefer to rename FeatureFlagEntity to FeatureFlag to avoid an exception for FeatureFlag.
WDYT @FelixMalfait?
There was a problem hiding this comment.
I'm ok with that, let's just double check if we have any conflicts
There was a problem hiding this comment.
Yes great let's rename FeatureFlagEntity to FeatureFlag
Replaced all instances of `FeatureFlagEntity` with `FeatureFlag` across the codebase for consistency and better naming alignment. This change affects module imports, service injections, TypeORM entities, and GraphQL field definitions.
Renamed `FeatureFlagEntity` to `FeatureFlag` and updated related references for clarity. Refactored mutation names like `CreateOneRelationMetadata` to `CreateOneRelationMetadataItem` for better alignment with naming conventions. These changes improve readability and maintain consistency across the codebase.
Fixes #9827
Also uncovered a conflict with
@objectType('Relation')and@objectType('relation)I don't want to address it in this PR so I will create a followup issue when we close this but I think there's a confusion between Relation/RelationMetadata, it's unclear what is what