Der type-Schlüssel im addAttribute()-Aufruf aus Kapitel 13 sieht harmlos aus, entscheidet aber über den kompletten Lese- und Schreibweg eines Attributs: Er landet unverändert als backend_type in eav_attribute und bestimmt damit, in welche der fünf Wertetabellen aus Kapitel 11 AbstractEntity beim Speichern greift.

Die vier tatsächlich genutzten backend_type-Werte

• varchar - title, reward_type. Kurze Zeichenketten bis 255 Zeichen, landen in mironsoft_loyalty_reward_entity_varchar.
• text - description. Beliebig lange Texte, landen in mironsoft_loyalty_reward_entity_text (SQL-Spaltentyp TEXT, kein Längenlimit wie bei varchar).
• int - points_cost, is_active. Ganzzahlen, landen in mironsoft_loyalty_reward_entity_int - auch der boolesche Wert is_active ist auf Datenbankebene ein int, nicht ein eigener Boolean-Typ.
• decimal - discount_value. Landet in mironsoft_loyalty_reward_entity_decimal, SQL-Typ DECIMAL(20,4) - exakt, im Gegensatz zu float/double, die für Geldbeträge grundsätzlich ungeeignet sind.

frontend_input ist nicht backend_type

Zwei unterschiedliche Konzepte, die leicht verwechselt werden: backend_type entscheidet, wo der Wert liegt, frontend_input entscheidet, welches Formularfeld im Admin angezeigt wird. is_active zeigt das deutlich: backend_type = int, aber frontend_input = boolean - ein Häkchen-Feld im Admin, gespeichert als 0/1 in einer _int-Zeile. reward_type genauso: backend_type = varchar, aber frontend_input = select mit dem RewardType-Source-Model aus Kapitel 13 als Optionslieferant.

Werte schreiben und lesen

Nach außen verhält sich das Model wie bei der flachen Ledger-Entity aus Kapitel 4 - AbstractModel stellt magische Getter/Setter über getData()/setData() bereit. Der Unterschied liegt vollständig im ResourceModel, nicht im Aufrufcode:

$reward = $this->rewardFactory->create();
$reward->setIdentifier('reward-10-euro-gutschein');
$reward->setTitle('10-Euro-Rabattgutschein');
$reward->setDescription('Einloesbar ab 500 Punkten.');
$reward->setPointsCost(500);
$reward->setDiscountValue('10.0000');
$reward->setRewardType(RewardType::TYPE_DISCOUNT);
$reward->setIsActive(true);

$this->rewardResource->save($reward);

// Sechs separate INSERTs/UPDATEs im Hintergrund: einer auf die Haupttabelle,
// je einer pro gesetztem Attribut auf die passende Wertetabelle.

$loadedReward = $this->rewardFactory->create();
$this->rewardResource->load($loadedReward, $reward->getEntityId());
echo $loadedReward->getPointsCost(); // int(500)
echo $loadedReward->getDiscountValue(); // string("10.0000")

Was das für die Spaltenwahl bedeutet

Der type-Wert ist keine Formalität, sondern eine echte Architekturentscheidung pro Attribut: varchar für kurze, durchsuchbare Zeichenketten, text nur für tatsächlich lange Inhalte (ein varchar-Feld mit 255 Zeichen für description hätte längere Beschreibungen schlicht abgeschnitten), int für Ganzzahlen und Booleans, decimal für alles, was mit Geld oder Prozentsätzen zu tun hat. Eine falsche Wahl lässt sich zwar per neuem Data Patch korrigieren (changeAttribute() mit einem neuen backend_type), erfordert dann aber eine Datenmigration bestehender Werte zwischen zwei Wertetabellen - Aufwand, der sich durch die richtige Wahl in Kapitel 13 komplett vermeiden lässt.

Mit den Attributen sauber typisiert und befüllbar geht es in Kapitel 15 an die Frage, wie sich mehrere Prämien gleichzeitig - gefiltert nach genau diesen Attributen - effizient laden lassen.