transform

func NewPersistentRecordTransformer ¶

func NewPersistentRecordTransformer(registry forma.SchemaRegistry) model.PersistentRecordTransformer

NewPersistentRecordTransformer creates a new PersistentRecordTransformer instance

func NewTransformer ¶

func NewTransformer(registry forma.SchemaRegistry) *transformer

NewTransformer creates a new Transformer instance backed by the provided schema registry.

func NormalizeDottedKeys ¶

func NormalizeDottedKeys(
	data map[string]any,
	cache forma.SchemaAttributeCache,
	arrays schemavalidate.ArrayPaths,
) map[string]any

NormalizeDottedKeys rewrites literal dotted keys into their nested paths, producing the document handed to the schema validator.

It is for the validator only. The writer keeps receiving the caller's original map, so flattenToAttributes and #312's dedupe remain the single authority on which record wins: records carry the spelling that produced them, and the last spelling replaces the whole logical attribute. Merging spellings into one document destroys those tags, so a normalized document cannot re-derive that precedence in every case — which is why it must never reach the write path. Nothing here can change which records are written.

What it is for: attribute names in this codebase are dotted, so a caller reading the metadata may address contact.email either as a nested object or as a literal key. Left literal, JSON Schema treats it as an unknown property — with no additionalProperties declared it passes validation and its value is never examined, making validation trivially bypassable (#314). Expanding it first means the value is checked like any other.

Interior paths are expanded too, not just leaf attributes: {"contact.snapshot": {"code": …}} hides "code" from validation exactly the way a literal leaf key hides its own value. The test is isKnownAttributeOrParent — the same predicate flattenToAttributes uses — so a name is expanded when the schema defines it or defines something beneath it. An unknown dotted key is left alone; the writer still rejects it with "attribute is not defined".

A dotted key is not expanded when the schema declares an array between the key's own position and its leaf, because it cannot be: nesting requirement.areas.city at the top level puts an object where the schema declares an array, and the caller gets a 400 naming a type they never sent. Such a value is therefore not validated at all — the documented limit of this function.

The discriminator is where the caller writes the key, not which attribute it names. The same name is expanded and validated when it is written inside an element of the array it lies under: within an element of requirement.areas the array is already behind us, so "city" lands in the right place, and a dotted "snapshot.code" inside a propertyInterests element nests legally. That is ArrayPaths.CrossesBelow asking the question relative to the current node. It holds unconditionally on the shipped schemas only because none of them nests an array inside an array.

Relation roots need no rule here, because the write paths hand this function a payload RelationIndex.StripComputedFields has already emptied of them: the strip deletes the whole relation subtree — the root and every dotted descendant such as contactSnapshot.name (#318) — so no name beneath a relation root is left to expand. Pinned by TestStripLeavesNothingCoveredForTheValidator.

That is a statement about those callers, not a guarantee this package can make. Each strip site is guarded on the caller holding a relation index (entity_crud_service.go, entity_batch_service.go), and a caller that skips the strip reaches this function with contactSnapshot.name still present, where the ordinary rule expands it like any other known dotted name. That expansion is what #314 carved out against, and the carve-out is gone (#318).

arrays comes from schemavalidate, the only place that knows which paths are arrays; the metadata cache records requirement.areas.city and contact.email identically. Passing a nil set is safe and means "nothing known to be an array".

When both spellings are present the literal wins, matching encoding/json's duplicate-key semantics. Keys are applied in sorted order, and for any dotted name X.Y the shorter spelling X sorts before X.Y, so the longer, more specific one is applied last.

That is not the writer's rule, and this document does not claim to reproduce it. The writer's dedupe drops the losing spelling's records for the whole logical attribute; here the losing spelling's *siblings* are merged in, which is what keeps every persisted value visible to the validator. At an array the two rules diverge outright — see mergeSlices for the false rejection that follows and why it is accepted.

The input is never mutated: maps and slices are rebuilt rather than shared.

func ToFloat64 ¶

func ToFloat64(v any) (float64, bool)

ToFloat64Ok is an exported helper that behaves like the legacy optimizer helper: it returns (float64, bool) where bool indicates success.