Magento 2: Was ist der Unterschied zwischen row_id und entity_id in den% _entity-Tabellen?

In Magento 1 gab es row_idin den Entitätstabellen keine Spalte mit dem Namen entity_id:

CREATE TABLE `catalog_category_entity` (
  `entity_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Entity ID',
  `entity_type_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Entity Type ID',
  `attribute_set_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attriute Set ID',
  `parent_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Parent Category ID',
  `created_at` timestamp NULL DEFAULT NULL COMMENT 'Creation Time',
  `updated_at` timestamp NULL DEFAULT NULL COMMENT 'Update Time',
  `path` varchar(255) NOT NULL COMMENT 'Tree Path',
  `position` int(11) NOT NULL COMMENT 'Position',
  `level` int(11) NOT NULL DEFAULT '0' COMMENT 'Tree Level',
  `children_count` int(11) NOT NULL COMMENT 'Child Count',
  PRIMARY KEY (`entity_id`),
  KEY `IDX_CATALOG_CATEGORY_ENTITY_LEVEL` (`level`),
  KEY `IDX_CATALOG_CATEGORY_ENTITY_PATH_ENTITY_ID` (`path`,`entity_id`)
) ENGINE=InnoDB AUTO_INCREMENT=943 DEFAULT CHARSET=utf8 COMMENT='Catalog Category Table'

Aber Magento 2 führt ein Konzept ein, von row_iddem der Primärschlüssel für eine Entität wird. Es scheint etwas mit der Versionierung des Kommentars zu tun zu haben:

CREATE TABLE `catalog_category_entity` (
  `row_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Version Id',
  `entity_id` int(10) unsigned NOT NULL COMMENT 'Entity Id',
  `created_in` bigint(20) unsigned NOT NULL COMMENT 'Update Id',
  `updated_in` bigint(20) unsigned NOT NULL COMMENT 'Next Update Id',
  `attribute_set_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attriute Set ID',
  `parent_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Parent Category ID',
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Creation Time',
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Update Time',
  `path` varchar(255) NOT NULL COMMENT 'Tree Path',
  `position` int(11) NOT NULL COMMENT 'Position',
  `level` int(11) NOT NULL DEFAULT '0' COMMENT 'Tree Level',
  `children_count` int(11) NOT NULL COMMENT 'Child Count',
  PRIMARY KEY (`row_id`),
  KEY `CATALOG_CATEGORY_ENTITY_LEVEL` (`level`),
  KEY `CATALOG_CATEGORY_ENTITY_CREATED_IN` (`created_in`),
  KEY `CATALOG_CATEGORY_ENTITY_UPDATED_IN` (`updated_in`),
  KEY `CAT_CTGR_ENTT_ENTT_ID_SEQUENCE_CAT_CTGR_SEQUENCE_VAL` (`entity_id`),
  CONSTRAINT `CAT_CTGR_ENTT_ENTT_ID_SEQUENCE_CAT_CTGR_SEQUENCE_VAL` FOREIGN KEY (`entity_id`) REFERENCES `sequence_catalog_category` (`sequence_value`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=956 DEFAULT CHARSET=utf8 COMMENT='Catalog Category Table'

Dies bereitet mir einige Ungewissheit, wenn ich EAV-Felder verknüpfen möchte, da sich die Typen jetzt auf row_idanstelle der folgenden Typen beziehen entity_id:

CREATE TABLE `catalog_category_entity_varchar` (
  `value_id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Value ID',
  `attribute_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attribute ID',
  `store_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Store ID',
  `row_id` int(10) unsigned NOT NULL COMMENT 'Version Id',
  `value` varchar(255) DEFAULT NULL COMMENT 'Value',
  PRIMARY KEY (`value_id`),
  UNIQUE KEY `CATALOG_CATEGORY_ENTITY_VARCHAR_ENTITY_ID_ATTRIBUTE_ID_STORE_ID` (`row_id`,`attribute_id`,`store_id`),
  KEY `CATALOG_CATEGORY_ENTITY_VARCHAR_ENTITY_ID` (`row_id`),
  KEY `CATALOG_CATEGORY_ENTITY_VARCHAR_ATTRIBUTE_ID` (`attribute_id`),
  KEY `CATALOG_CATEGORY_ENTITY_VARCHAR_STORE_ID` (`store_id`),
  CONSTRAINT `CATALOG_CATEGORY_ENTITY_VARCHAR_STORE_ID_STORE_STORE_ID` FOREIGN KEY (`store_id`) REFERENCES `store` (`store_id`) ON DELETE CASCADE,
  CONSTRAINT `CAT_CTGR_ENTT_VCHR_ATTR_ID_EAV_ATTR_ATTR_ID` FOREIGN KEY (`attribute_id`) REFERENCES `eav_attribute` (`attribute_id`) ON DELETE CASCADE,
  CONSTRAINT `CAT_CTGR_ENTT_VCHR_ROW_ID_CAT_CTGR_ENTT_ROW_ID` FOREIGN KEY (`row_id`) REFERENCES `catalog_category_entity` (`row_id`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=266383 DEFAULT CHARSET=utf8 COMMENT='Catalog Category Varchar Attribute Backend Table'

Derzeit in der Entitätstabelle row_idund entity_idsind die gleichen:

select row_id, entity_id from catalog_category_entity limit 3;        
+--------+-----------+
| row_id | entity_id |
+--------+-----------+
|      1 |         1 |
|      2 |         2 |
|      3 |         3 |
+--------+-----------+
3 rows in set (0.00 sec)

Ich bin mir nicht sicher, wo sich die Umstände row_idändern und welche Auswirkungen dies auf das Magento-System haben wird. Ich habe nach einer Dokumentation zu dieser Funktion gesucht, kann aber keine finden.

Ich möchte folgendes wissen:

• Kann dieselbe Entität mehrere row_ids haben?
  • Wenn ja, wie ist die aktive Entität definiert?
  • Wenn nicht, welchen Mechanismus verwendet Magento, um diese zu aktualisieren.
• Was ist die Hauptverwendung dieser Funktion und gibt es Dokumentation?
  • http://devdocs.magento.com/guides/v2.1/extension-dev-guide/staging/Staging.html

Von dem, was ich auf diesem gefunden habe, row_idist der Bezeichner für die Zeile, während entity_iddie tatsächliche Entität ist.

Es gibt Situationen, in denen ein geplantes Update für einen festgelegten Zeitraum ausgeführt wird. In diesem Fall wird eine neue Zeile erstellt, die mit den Varianten verknüpft wird. Diese Zeile eav_attributekann entity_idbei der Ausgabe einer neuen Zeile beibehalten werden. row_idAnschließend wird die Zeile in row_idgeändert neue temporäre Entität und dann zurück zum Original, sobald der Zeitplan abgeschlossen ist.

Es kann andere Anwendungsfälle geben, in denen sie davon Gebrauch machen. Dies war einer, den ich miterlebt habe und der beleuchtet, wie er verwendet werden kann.

Das entity_idwird nur in der Magento 2 EE Version verwendet. Es wird als Index verwendet, der beim catalog_category_entityZeigen auf definiert wird sequence_catalog_category.

Die Sequenztabellen werden im Allgemeinen für die Funktion zur Datenbankaufteilung verwendet.

Ich würde sagen, dass der Zweck darin besteht, die Kompatibilität mit Magento 1 zu gewährleisten. Wenn Sie Daten von m1 nach m2 migrieren müssen, benötigen Sie diese Beziehung.