Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Implement "migrationActions" to allow migration of data / data conversions between syncActions updates

Abierto
  • ¿Algo no está bien?
#1,429 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
javascript, nodejs
Área
api, backend-api-design

Línea de trabajo

El issue no especifica archivos del repositorio, pruebas ni un punto de entrada de migración existente. Empieza localizando la implementación de syncActions y el issue relacionado #355, y determina después cómo se gestionan actualmente los campos personalizados y los atributos de producto. La tarea estaría terminada cuando exista un diseño de migración acordado, un comportamiento de conversión, acciones de limpieza y cobertura para los tipos de recursos compatibles.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Node SDK Type: Discussion

Hi,
wouldn't it be awesome if we could update custom types or product types field definitions with a migration strategy to prevent data loss? As far I know, It doesn't exist any assistant in migrating, for example, a ProductVariant attribute between different field types.

Scope:

It will affect custom field definitions (Types, ProductTypes). That means migration support for product attributes, custom attributes of all supported resources. For the base fields, it's not necessary since the type will never change.

Use cases:

  • A user might want to change the field String to LocalizedString
  • A user might want to change the field String to Number
  • A user might want to change the field String to SetOfStrings

With migrationActions I think about a companion to control how the old data is preserved.

That feature request comes from the daily practice experience with CT. Our product is very new and the model is constantly evolving.

I think this feature would bring a lot of value to the platform because it allows writing migrations scripts in a convenient and safe way.

That migration tool can be implemented in a very generic way so we don't need to respect every resource type individually.

It would require that "syncActions" can handle changes in custom attributes. I have seen that the current implementation respects only base fields or the implementation is just not complete.

Out of scope:

Updates in base fields are covered by sync-actions whereby the implementation doesn't cover all cases e.g there is no support for custom fields in types or product-types. That half complete implementation is really hard to track.

It's also really hard to find out what sync really means in the context of the "resourceType". As a customer, I would expect that sync checks EVERYTHING or at least the documentation should clarify the exact behavior.

Related issues:

https://github.com/commercetools/nodejs/issues/355

Some code to illustrate the migration approach:

1. Determine attribute changes
import { typeConversionMap } from '@commercetools/migration-actions';

const updateActions = productTypeSync.buildActions(next, previous, { preservePreviousFields: true });

// for example the attribute type has changed from "String" to "Number"
// we will create a new field to hold the new value + saving type and name differences in the attribute name

updateActions = [
  {
    action: 'addAttributeDefinition',
    attribute: {
      name: 'previous-attribute-name__string-number__next-attribute-name',
      type: { name: 'Number' }
    }
  }
];
2. Apply changes and create temporary fields to hold the new value + conversion information
client.execute(updates);
3. Fetch records which should be migrated
// for example
const productA = {
  attributes: [
    { name: 'previous-attribute-name__string-number__next-attribute-name', value: null },
    { name: 'previous-attribute-name', value: '2' }
  ]
};
4. We will create actions to migrate all fields

With the convention "old__string-number__new" or even "old__oldType-newType__old" we know how to convert that field.

const typeConversionHelper = {
  [[typeConversionMap.String][typeConversionMap.Number]]: old => parseInt(old),
  [[typeConversionMap.String][typeConversionMap.ListString]]: old => [old.toString()],
  [[typeConversionMap.String][typeConversionMap.LocalizedString]]: old => { en: old }
};
const dataActions = migrationSync.buildActions([productA], { conversionHelper });

dataActions = {
  url: 'https://api/products/....',
  body: {
    actions: [
      {
        action: 'setAttribute',
        name: 'previous-attribute-name__string-number__next-attribute-name',
        value: 2
      }
    ]
  }
};
5. Determine changes based on the naming convention and remove old fields and rename temporary fields
const dataActions = migrationSync.migrationCleanActions([productA]);

dataActions = [
  {
    action: 'removeAttributeDefinition',
    name: 'previous-attribute-name'
  },
  {
    action: 'changeAttributeName',
    attributeName: 'previous-attribute-name__string-number__next-attribute-name',
    newAttributeName: 'next-attribute-name'
  }
];
Lenguaje dominante
JavaScript
Estrellas
78
Forks
70
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de commercetools/nodejs

Todos los issues de commercetools/nodejs

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.