Przeznaczenie tabel „eav_”

Zawsze zastanawiałem się, jakie jest znaczenie tabel:

eav_entity  
eav_entity_datetime
eav_entity_decimal
eav_entity_int
eav_entity_store
eav_entity_text

Zawsze są puste. Są one tworzone w wersjach wcześniejszych niż 1.6 app/code/core/Mage/Eav/sql/eav_setup/mysql4-install-0.7.0.phpi później przeniesione do skryptu instalacyjnego dla wersji 1.6+. /app/code/core/Mage/Eav/sql/eav_setup/install-1.6.0.0.php
Widziałem, że istnieje model zasobów powiązany z jedną z tabel Mage_Eav_Model_Resource_Entity_Store(być może są inne), ale nic się z tym nie dzieje.

Czy te tabele mają jakieś zastosowanie, czy jest to inna „funkcja”, która została uruchomiona i nie została zaimplementowana, na przykład wersja układu lub okruszki administracyjne .

Domyślam się, że jest to częściowo dziedzictwo i wzorzec „wygody” dla programistów do wdrażania „ogólnych” bytów / modeli.

Jak już wspomniałeś, powiązane tabele są zwykle puste. Powodem jest to, że żadna z podstawowych jednostek EAV nie używa tej „domyślnej” struktury tabeli jednostek. Oto tabele encji z instalacji 1.8:

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)

Na przykładzie modelu klienta możemy zobaczyć, że model zasobów Mage_Customer_Model_Resource_Customerrozszerza się Mage_Eav_Model_Entity_Abstract, Źródło .

Uwaga : Przed wersją 1.6 Mage_Customer_Model_Entity_Customerrozszerzono także model zasobów dla jednostki klienta Mage_Eav_Model_Entity_Abstract, Źródło .

Jeśli zbadamy Mage_Eav_Model_Entity_Abstractklasę, znajdziemy getEntityTablemetodę. Ta metoda służy do określania, której tabeli należy użyć podczas budowania zapytań podczas typowych operacji CRUD. Inną interesującą metodą jest getValueTablePrefix. To określa prefiks tabel dla tabel danych „typ”, *_datetime, *_decimal, *_varchari tak dalej.

Zaglądając do źródła tych metod ( tu i tutaj ).

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;
    }

W powyższej metodzie możemy zobaczyć, że jeśli typ encji nie definiuje niestandardowej tabeli, domyślnie jest to ustawiane Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE. Wartością tej stałej jest 'eav/entity', która z kolei zamienia się w eav_entitytabelę (zakładając, że w aplikacji nie ma skonfigurowanego prefiksu tabeli). Druga metoda, o której wspomniałem, opiera się na tej tabeli jako prefiks, jeśli żadna nie została skonfigurowana dla danej jednostki. Jeśli sprawdzisz wartości w eav_entity_typetabeli dla value_table_prefixkolumny, zauważysz, że wszystkie one są 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;
    }

Logika w metodzie jest raczej prosta, jeśli nie zdefiniowano prefiksu wartości, użyj nazwy tablicy encji jako prefiksu.

Zakładam, że skoro te tabele są w Magento od tak dawna, najlepiej pozostawić je dla kompatybilności wstecznej, niż je całkowicie usunąć. Pomysł, który według mnie zamierzali, był łatwą w użyciu strukturą encji / modelu, którą inni programiści mogliby po prostu rozszerzyć o kilka klas i mieć te „dynamiczne” atrybuty, które można zmienić za pośrednictwem administratora (patrz produkty z katalogu i modele klientów). Niestety implementacja i praktyka tego wzorca nie wydaje się dobrze skalować i prowadzi do problemów. Nigdy nie widziałem tej struktury używanej na wolności, prawdopodobnie z powodu braku dokumentacji i przykładowych przypadków użycia lub słabej wydajności.

Nie jestem głównym programistą (ani archeologiem), ale to, co zbieram ze kodu i struktur danych, mam nadzieję, że to pomoże rzucić nieco światła.

Rozważ ten fragment kodu w podstawowym modelu zasobów EAV.

#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;
}

Ta metoda pobiera nazwę tabeli jednostki podstawowej do użycia do przechowywania. Tak więc w przypadku modelu zasobów produktu metoda ta zwróci catalog_product_entity(zakładając, że nie ustawiono prefiksu nazwy tabeli)

Te cztery linie są najbardziej odkrywcze.

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

Jeśli jednostka nie ma ustawionej tabeli, używana jest następująca stała

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

Ten eav/entityciąg jest następnie używany do wyszukiwania nazwy tabeli

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

Który pobiera nazwę tabeli z konfiguracji.

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

Ach ha! Jeśli typ jednostki eav nie ma ustawionej nazwy tabeli, Magento użyje eav_entitytabel jako domyślnej lokalizacji przechowywania.

Oryginalny zespół inżynierów Magento był zachwycony koncepcją EAV - podczas gdy nowoczesne Magento to zmniejszyło, modele EAV były preferowanym rozwiązaniem wielu problemów.

Rozsądne wydaje się założenie / spekulowanie, że początkowa przedpremierowa implementacja EAV zawierała wszystkie dane w tej centralnej eav_entitytabeli typów (wspólny wzorzec na platformach korporacyjnych), a typy jednostek pojawiły się później.

Inną (przekonującą) możliwością jest to, że ta funkcja miała umożliwić „bezobsługowe” modele CRUD. Teoretycznie byłoby możliwe wstawienie poprawnych informacji o typie EAV, skonfigurowanie klas modelu / zasobu / kolekcji i przechowywanie danych w tych eav_entitytabelach. Odejście Magento od EAV i skupienie się na zespole inżynierów po uruchomieniu na funkcjach użytkowników końcowych sprawiło, że ta funkcja zniknęła we mgle. Byłbym ciekawy, czy to zadziała, ale nie chciałbym na nim polegać, ponieważ nie jest to ścieżka do kodu, na którą zwrócono dużą uwagę, i wątpliwe jest, aby TAF obejmował jego użycie.

Magento używa modelu danych o nazwie „Wartość atrybutu jednostki” dla wielu swoich funkcji (klientów, produktów itp.). To pozwala dynamicznym atrybutom w systemie bez konieczności restrukturyzacji i modyfikowania tabel w locie. EAV Na Wikipedii