Dugaan saya adalah bagian warisan dan pola "kenyamanan" bagi pengembang untuk menerapkan entitas / model "umum".
Seperti yang telah Anda nyatakan, tabel terkait biasanya kosong. Alasannya adalah bahwa tidak ada entitas EAV inti yang menggunakan struktur tabel entitas "default" ini. Ini adalah tabel entitas dari instalasi 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)
Menggunakan model Pelanggan sebagai contoh, kita dapat melihat bahwa model sumber daya Mage_Customer_Model_Resource_Customer
meluas Mage_Eav_Model_Entity_Abstract
, Sumber .
Catatan : Sebelum 1.6 model sumber daya untuk entitas pelanggan Mage_Customer_Model_Entity_Customer
juga diperluas Mage_Eav_Model_Entity_Abstract
, Sumber .
Jika kita memeriksa Mage_Eav_Model_Entity_Abstract
kelas kita menemukan getEntityTable
metode. Metode ini digunakan untuk menentukan tabel mana yang akan digunakan ketika membangun kueri selama operasi CRUD umum. Metode lain yang menarik adalah getValueTablePrefix
. Hal ini menentukan awalan untuk tabel data "jenis" meja, *_datetime
, *_decimal
, *_varchar
dan sebagainya.
Mengintip sumber untuk metode tersebut (di sini dan di sini ).
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;
}
Dalam metode di atas kita dapat melihat bahwa jika tipe entitas tidak mendefinisikan tabel kustom itu defaultnya Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE
. Nilai konstanta itu adalah 'eav/entity'
, yang pada gilirannya akan berubah menjadi eav_entity
tabel (dengan asumsi tidak ada awalan tabel yang dikonfigurasi dalam aplikasi). Metode kedua yang saya sebutkan jatuh kembali pada tabel ini sebagai awalan jika tidak ada yang dikonfigurasi untuk entitas yang diberikan. Jika Anda memeriksa nilai dalam eav_entity_type
tabel untuk value_table_prefix
kolom Anda akan melihat bahwa semuanya 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 dalam metode ini agak sederhana, jika tidak ada nilai awalan yang didefinisikan menggunakan nama tabel entitas sebagai awalan.
Saya berasumsi bahwa karena tabel-tabel ini sudah ada di Magento sejak lama, yang terbaik adalah membiarkannya untuk kompatibilitas mundur daripada menghapusnya langsung. Gagasan yang saya yakini akan mereka gunakan adalah struktur entitas / model yang mudah digunakan sehingga pengembang lain hanya dapat memperluas beberapa kelas dan memiliki atribut "dinamis" yang dapat diubah melalui admin (lihat katalog produk dan model pelanggan). Sayangnya implementasi dan praktik pola tersebut tampaknya tidak berkembang dengan baik dan menyebabkan masalah. Saya belum pernah melihat struktur ini digunakan di alam, mungkin karena kurangnya dokumentasi dan contoh kasus penggunaan atau kinerja yang buruk.
Saya bukan pengembang inti (atau arkeolog), tetapi itulah yang saya kumpulkan dari struktur kode dan data, semoga ini membantu menjelaskan.