Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#1,429 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
javascript, nodejs
領域
api, backend-api-design

調査の方向性

この issue では、リポジトリのファイル、テスト、既存のマイグレーションのエントリーポイントが指定されていません。まず syncActions の実装と関連する issue #355 を見つけ、次にカスタムフィールドと商品属性が現在どのように処理されているかを確認してください。完了とみなすには、合意されたマイグレーション設計、変換動作、クリーンアップアクション、およびサポート対象のリソースタイプに対するカバレッジが必要です。

索引モデルが issue の本文から書いたものです。

説明

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'
  }
];
主要言語
JavaScript
スター
77
フォーク
70
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

commercetools/nodejs のほかの issue

commercetools/nodejs の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。