Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,429 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
javascript, nodejs
Lĩnh vực
api, backend-api-design

Hướng nghiên cứu

Issue không nêu tên các tệp trong repository, các bài kiểm thử hoặc một điểm vào migration hiện có. Hãy bắt đầu bằng cách xác định phần triển khai syncActions và issue liên quan #355, sau đó xác định cách các trường tùy chỉnh và thuộc tính sản phẩm hiện đang được xử lý. Công việc được coi là hoàn tất khi có thiết kế migration đã được thống nhất, hành vi chuyển đổi, các hành động dọn dẹp và độ bao phủ cho các loại tài nguyên được hỗ trợ.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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'
  }
];
Ngôn ngữ chính
JavaScript
Star
78
Fork
70
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của commercetools/nodejs

Tất cả issue của commercetools/nodejs

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.