Plan a Znode 9 product attribute migration without confusing it with a Store attribute
A product attribute belongs to PIM metadata and a product record. It is not a renamed Store global-attribute migration. Use a read-only schema map first, then build and test a version-pinned migration in a disposable database.
In this guide
Choose the value owner before writing SQL
A product attribute describes a catalog item, such as a fictional MaterialGrade. A Store attribute describes a portal or buying context. Those owners travel through different metadata and value relationships, so substituting table names from a global-attribute script is unsafe.
Write down the target entity, attribute type, locale, product family, Admin surface, publication path, and whether the value is free text or a controlled option. A migration can create metadata successfully while leaving the field unavailable to editors or absent from a published product.
Map the target patch read-only
Start with a disposable copy of the exact target schema. The query below is a discovery aid, not a mutation or a cross-version schema contract. Compare its results with a known product attribute of the same intended type before designing inserts.
inspect-pim-attribute-shape.sql sql
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME LIKE 'ZnodePim%'
AND (COLUMN_NAME LIKE '%Attribute%' OR COLUMN_NAME LIKE '%Family%'
OR COLUMN_NAME LIKE '%Group%' OR COLUMN_NAME LIKE '%Locale%')
ORDER BY TABLE_NAME, ORDINAL_POSITION;Build the migration as a small owned graph
The graph normally includes an attribute definition, a localized display label, the intended group and family relationship, and a product value path. Dropdown attributes add a separate default-option and localized-option layer. Treat each layer as a distinct prerequisite and reject a conflicting existing definition instead of changing its type in place.
Resolve stable codes to IDs inside the migration and fail when a lookup is absent or ambiguous. Scope every read and insert by the target entity and locale. A rerun plan must account for partial setup, such as a definition that exists without its group mapping.
- Create a new numbered migration rather than editing a journaled file.
- Use a transaction only when the project runner and deployment policy support it.
- Verify a synthetic product in Admin, then publish or refresh through the declared version's supported path.
Verification is broader than rows
Use a repeatable verification record: expected database rows, the field location in Admin, behavior for an empty product, one saved value, and the published product projection. Repeat the same record after a rerun and a deliberately conflicting attribute definition. That sequence establishes the migration's creation, rerun, and conflict behavior for the selected patch.
References and further reading
Bring your next engineering question.
Need help planning a safe catalog-data migration?
Independent guidance from GCG. Znode is a trademark of its owner. Examples use fictional data and are not official platform documentation. Suggest a correction.