You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Three Person.Language scalar attributes carry names that are invalid GraphQL identifiers and violate the LIF naming convention (scalars must be camelCase with no special characters — see docs/specs/data-model-rules.md → Naming Styles):
iSO639-2LangCode
iSO639-3LangCode
iSO639-5LangFamily
The hyphen makes them illegal GraphQL names. Pre-#1012 the GraphQL schema build aborted on the first one (GraphQLError: Names must only contain [_a-zA-Z0-9] but 'iSO639-2LangCode' does not), crash-looping graphql-org1 in both dev and demo (#1011). #1012 hardens the generator so a bad name can't crash the service — but those three fields are still name-inconsistent across GraphQL / Query Planner / the dataclass attr, so they return null and never round-trip data. The rename is the actual fix for the fields. (#1012 = safety net; this = correctness.)
Where the names live (checked-in source of truth):
Decide the canonical replacement names (camelCase, no hyphen) — e.g. iso6392LangCode / iso6393LangCode / iso6395LangFamily (exact form is a data-model-owner call; CEDS-derived).
Grep for any references in .graphql queries, information_sources_config*.yml, sample data, tests.
Related:#1011 / #1012 (the crash + hardening). Also surfaces a broader gap: there's no recorded decision/ADR reconciling source-standard field names (CEDS, etc.) with LIF's naming convention and technology constraints (GraphQL/Python/JSON), and the convention is unenforced by tooling. Tracking that separately (ADR + non-tech docs + lint).
Describe the issue
Three
Person.Languagescalar attributes carry names that are invalid GraphQL identifiers and violate the LIF naming convention (scalars must be camelCase with no special characters — seedocs/specs/data-model-rules.md→ Naming Styles):iSO639-2LangCodeiSO639-3LangCodeiSO639-5LangFamilyThe hyphen makes them illegal GraphQL names. Pre-#1012 the GraphQL schema build aborted on the first one (
GraphQLError: Names must only contain [_a-zA-Z0-9] but 'iSO639-2LangCode' does not), crash-looping graphql-org1 in both dev and demo (#1011). #1012 hardens the generator so a bad name can't crash the service — but those three fields are still name-inconsistent across GraphQL / Query Planner / the dataclass attr, so they return null and never round-trip data. The rename is the actual fix for the fields. (#1012 = safety net; this = correctness.)Where the names live (checked-in source of truth):
reference_data/schemas/lif-schema.json(~L5536)projects/lif_mdr_database/backup.sql(local MDR seed)sam/mdr-database/flyway/flyway-files/flyway/sql/mdr/V1.1__metadata_repository_init.sqlWork required:
iso6392LangCode/iso6393LangCode/iso6395LangFamily(exact form is a data-model-owner call; CEDS-derived).lif-schema.json+backup.sql+ (for fresh inits)V1.1.V1.x, idempotent) to rename the elements in already-migrated dev and demo MDR DBs —V1.1won't re-run on deployed envs..graphqlqueries,information_sources_config*.yml, sample data, tests.Related: #1011 / #1012 (the crash + hardening). Also surfaces a broader gap: there's no recorded decision/ADR reconciling source-standard field names (CEDS, etc.) with LIF's naming convention and technology constraints (GraphQL/Python/JSON), and the convention is unenforced by tooling. Tracking that separately (ADR + non-tech docs + lint).