'Ea__' tablolarının amacı

Her zaman tabloların ne anlama geldiğini merak ettim:

eav_entity  
eav_entity_datetime
eav_entity_decimal
eav_entity_int
eav_entity_store
eav_entity_text

Her zaman boşlar. 1.6 app/code/core/Mage/Eav/sql/eav_setup/mysql4-install-0.7.0.phpve daha önceki sürümlerde 1.6'da sürümler halinde oluşturuldular ve daha sonra 1.6 + sürümleri için kurulum komut dosyasına taşındılar /app/code/core/Mage/Eav/sql/eav_setup/install-1.6.0.0.php
Tablolardan birine Mage_Eav_Model_Resource_Entity_Store(belki başkaları var) bağlı bir kaynak modeli olduğunu gördüm, ancak hiçbir şey olmuyor.

Bu tablolar için herhangi bir kullanım var mı veya bu örneğin düzen sürümü veya yönetici kırıntıları gibi başlatılmış ve uygulanmamış başka bir "özellik" var .

Benim tahminim, geliştiricilerin "genel" varlıkları / modelleri uygulamalarının bir kısmı miras ve bir "kolaylık" kalıbı olduğudur.

Belirttiğiniz gibi, ilgili tablolar genellikle boştur. Bunun nedeni, çekirdek EAV varlıklarının hiçbirinin bu "varsayılan" varlık tablosu yapısını kullanmamasıdır. Bunlar 1.8 kurulumundaki varlık tablolarıdır:

mysql> select distinct(entity_table) from eav_entity_type;
+-------------------------+
| entity_table            |
+-------------------------+
| customer/entity         |
| customer/address_entity |
| sales/order             |
| sales/order_entity      |
| catalog/category        |
| catalog/product         |
| sales/quote             |
| sales/quote_address     |
| sales/quote_entity      |
| sales/quote_item        |
| sales/invoice           |
+-------------------------+
11 rows in set (0.00 sec)

Örnek olarak Müşteri modeli kullanarak, kaynak modeli olduğunu görebilirsiniz Mage_Customer_Model_Resource_Customeruzanır Mage_Eav_Model_Entity_Abstract, Kaynak .

Not : 1.6'dan önce müşteri kuruluşu için kaynak modeli Mage_Customer_Model_Entity_Customerde genişletilmiştir Mage_Eav_Model_Entity_Abstract, Kaynak .

Mage_Eav_Model_Entity_AbstractSınıfı incelersek bir getEntityTableyöntem buluruz . Bu yöntem, yaygın CRUD işlemleri sırasında sorgular oluştururken hangi tablonun kullanılacağını belirlemek için kullanılır. İlgilenilen başka bir yöntem getValueTablePrefix. Bu veriler "tip" tabloları için masalar öneki belirler *_datetime, *_decimal, *_varcharve böyle devam eder.

Bu yöntemlerin ( burada ve burada ) kaynağına bakmak .

public function getEntityTable()
    {
        if (!$this->_entityTable) {
            $table = $this->getEntityType()->getEntityTable();
            if (!$table) {
                $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
            }
            $this->_entityTable = Mage::getSingleton('core/resource')->getTableName($table);
        }

        return $this->_entityTable;
    }

Yukarıdaki yöntemde, varlık türü varsayılan olarak özel bir tablo tanımlamazsa görebiliriz Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE. Bu sabitin değeri 'eav/entity', eav_entitytabloya dönüştürülür (uygulamada yapılandırılmış tablo öneki olmadığı varsayılarak). Bahsettiğim ikinci yöntem, belirtilen varlık için hiçbiri yapılandırılmadıysa bu tabloya önek olarak geri döner. eav_entity_typeTablodaki değerleri value_table_prefixsütun için incelerseniz bunların hepsinin olduğunu göreceksiniz NULL.

public function getValueTablePrefix()
    {
        if (!$this->_valueTablePrefix) {
            $prefix = (string)$this->getEntityType()->getValueTablePrefix();
            if (!empty($prefix)) {
                $this->_valueTablePrefix = $prefix;
                /**
                * entity type prefix include DB table name prefix
                */
                //Mage::getSingleton('core/resource')->getTableName($prefix);
            } else {
                $this->_valueTablePrefix = $this->getEntityTable();
            }
        }

        return $this->_valueTablePrefix;
    }

Yöntemdeki mantık oldukça basittir, herhangi bir değer öneki tanımlanmamışsa varlık tablosu adını önek olarak kullanın.

Bu tabloların Magento'da çok uzun süre bulunduğundan, bunları geriye doğru uyumluluk için onları açık bir şekilde kaldırmaktan daha iyi bırakacağını varsayıyorum. Onların gittiklerine inanıyorum, diğer geliştiricilerin sadece birkaç sınıfı genişletebileceği ve yönetici aracılığıyla değiştirilebilecek bu "dinamik" özelliklere sahip olabileceği kullanımı kolay bir varlık / model yapısıydı (katalog ürünlerine ve müşteri modellerine bakın). Maalesef, söz konusu modelin uygulanması ve uygulanması iyi ölçeklenmemiş gibi görünüyor ve sorunlara yol açıyor. Muhtemelen belgeleme ve örnek kullanım durumları veya düşük performans nedeniyle, bu yapıyı vahşi doğada hiç görmedim.

Ben çekirdek geliştirici (veya arkeolog) değilim ama kod ve veri yapılarından topladığım şey, umarım biraz ışık tutmaya yardımcı olur.

Temel EAV kaynak modelindeki bu kod parçasını düşünün.

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
public function getEntityTable()
{
    if (!$this->_entityTable) {
        $table = $this->getEntityType()->getEntityTable();
        if (!$table) {
            $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
        }
        $this->_entityTable = Mage::getSingleton('core/resource')->getTableName($table);
    }

    return $this->_entityTable;
}

Bu yöntem, depolama için kullanılacak temel varlık tablosu adını alır. Dolayısıyla, bir ürünün kaynak modeli için bu yöntem geri döner catalog_product_entity(tablo adı öneki ayarlanmadığı varsayılarak)

Bu dört çizgi en açıklayıcıdır.

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
$table = $this->getEntityType()->getEntityTable();
if (!$table) {
    $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
}

Varlığın ayarlanmış bir tablosu yoksa, aşağıdaki sabit kullanılır

#File: app/code/core/Mage/Eav/Model/Entity.php
const DEFAULT_ENTITY_TABLE      = 'eav/entity';

Bu eav/entitydize daha sonra bir tablo adını aramak için kullanılır

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
Mage::getSingleton('core/resource')->getTableName($table);

Hangi yapılandırma adını tablodan koparır.

<!-- File: app/code/core/Mage/Eav/etc/config.xml -->
<entity>
    <table>eav_entity</table>
</entity>

Ah ha! Bir tablo öğesi türünde ayarlanmış bir tablo adı yoksa, Magento eav_entitytabloları varsayılan depolama konumu olarak kullanır.

Orijinal Magento mühendislik ekibi EAV konseptine aşıktı - modern Magento bunu geri ölçeklerken, EAV modelleri birçok sorun için tercih edilen çözümdü.

İlk ön sürüm EAV uygulamasının bu merkezi tür tablosundaki (kurumsal platformlarda ortak bir şablon) tüm verileri depoladığını varsaymak / spekülasyon yapmak makul görünmektedir eav_entityve varlık türleri daha sonra ortaya çıkmıştır.

Başka bir (zorlayıcı) olasılık, bu özelliğin "tablodan bağımsız" CRUD modellerini etkinleştirmek için tasarlanmış olmasıdır. Teorik olarak, doğru EAV tipi bilgileri eklemek, model / kaynak / toplama sınıflarınızı ayarlamak ve bu eav_entitytablolarda veri depolamak mümkün olacaktır . Magento'nun EAV'dan uzaklaşması ve lansman sonrası mühendislik ekibine son kullanıcı özelliklerine odaklanması, bu özelliğin buğunun içine kayması anlamına geliyordu. Bunun işe yarayıp yaramadığını merak ederken, çok fazla ilgi gören bir kod yolu olmadığına güvenmek istemem ve TSK'nın kullanımını kapsadığı şüpheli.

Magento, birçok işlevi (müşteriler, ürünler, vb.) İçin "Varlık Özellik Değeri" adlı bir veri modeli kullanır. Bu, tabloları anında yeniden yapılandırmaya ve değiştirmeye gerek kalmadan sistemdeki dinamik niteliklere izin veren şeydir. Wikipedia'da EAV