Posting in the Magento forums has been disabled pending the implementation of a new and improved forum solution which should better serve the community.

For new questions please post at magento.stackexchange.com, the community-run support site for the Magento community. We will be providing updates on the new forum solution soon. For questions or concerns please email community@magento.com.

Magento Forum

Page 1 of 2
Magento 2
 
ArtArtArt
Sr. Member
 
Total Posts:  166
Joined:  2010-02-02
 

Всем добрый день!
Немного погуглив, выяснил, что Magento 2 интенсивно разрабатывается. Код новой версии (рабочий вариант) доступен здесь. Вроде, все хорошо, но ходят слухи, что в новой версии собираются отказаться от EAV, возможно даже и в каталоге. Что, на мой взгляд, крайне плохо. Теряется одно из основных преимуществ Magento. Конечно, EAV медленнее, чем плоские таблицы, но никто не принуждает при каждом запросе дергать базу. Закэшировал данные - и пользуйся на здоровье!
Хотелось бы услышать мнение уважаемого сообщества.

 
Magento Community Magento Community
Magento Community
Magento Community
 
Rugento
Guru
 
Avatar
Total Posts:  540
Joined:  2008-11-15
Russia, Vologda
 

Да, к EAV уже привыкли, если не будет нужно много чего переписывать в модулях.
Еще jquery обещали, когда смотрел код не нашел)) жаль если не будет.

 
Magento Community Magento Community
Magento Community
Magento Community
 
ArtArtArt
Sr. Member
 
Total Posts:  166
Joined:  2010-02-02
 

Дело не только в привычке. А как же описание типов товаров через наборы атрибутов? А как же возможность добавить Клиенту (Customer) новые свойства? Все в плоские таблицы писать? Я тестировал каталог на EAV, не плоский, при количестве товаров в несколько сотен тысяч. При грамотном кэшировании база дергается нечасто, да и заполнение коллекций происходит так же не часто. Много ли у нас магазинов с сотнями тысяч товарных предложений? Ну а если это гипермаркет и предложений миллионы, тогда, наверное, не Magento использовать надо или оптимизацией под конкретный проект заняться. Я думаю, разработчики стремятся к упрощению, в первую очередь, чтобы сделать продукт максимально массовым. Но если разработчик не может разобраться в EAV, то ему просто надо учиться еще, он и без EAV такого понапишет, что потом волосы по всему телу у заказчика дыбом стоять будут.
Если EAV уберут - Magento превратится в “одну из” систему электронной коммерции, их много. А сейчас она уникальна, и во многом благодаря этому функционалу.

 
Magento Community Magento Community
Magento Community
Magento Community
 
Rugento
Guru
 
Avatar
Total Posts:  540
Joined:  2008-11-15
Russia, Vologda
 

Согласен EAV нужно оставить.
И еще были бы очень кстати функции: сладской учет на несколько складов и для конфиг. товара брать цены и значения из подчиненных товаров. Пожалуй, это самое востребованное, чего сейчас нет.

 
Magento Community Magento Community
Magento Community
Magento Community
 
ArtArtArt
Sr. Member
 
Total Posts:  166
Joined:  2010-02-02
 
Rugento - 22 February 2012 01:58 AM

И еще были бы очень кстати функции: сладской учет на несколько складов и для конфиг. товара брать цены и значения из подчиненных товаров. Пожалуй, это самое востребованное, чего сейчас нет.

Ну, это можно и модулями решить.
Да, кстати, насчет JQuery, вроде как решили на него переходить.

 
Magento Community Magento Community
Magento Community
Magento Community
 
paulborsky
Member
 
Avatar
Total Posts:  31
Joined:  2009-01-14
Russia
 

Вот Вам презентация от Дмитрия Сороки, если не видели :)

File Attachments
Magento_2_By_SorokaDmitry.pdf  (File Size: 805KB - Downloads: 306)
 
Magento Community Magento Community
Magento Community
Magento Community
 
ArtArtArt
Sr. Member
 
Total Posts:  166
Joined:  2010-02-02
 

Еще интересный момент…
Как я понял, разработчики хотят отказаться от code pool, вроде как при этом компиляция не нужна, и поиск по code pool не нужен - так быстрее. Не могу согласиться. Компиляция не только позволяет не просматривать code pool при каждом запросе, там еще происходит слияние нескольких, наиболее часто используемых, файлов в один. При сочетании с кэшером опкода - некислый прирост производительности, особенно на VPS. В принципе, при таком тяжелом движке, я не совсем понимаю чем они компенсировать отсутствие компилятора намерены. Ну, а то, что code pools не раз выручали - факт. Например, есть в ядре ошибка, как перекрыть код ядра? Модули не всегда помогают. Очень много классов унаследованы от одного, в ядре. Сейчас - перенес в local code pool и поправил. А как быть при отсутствии code pool? Перекрывать все классы - наследники?
У меня складывается впечатление, что сейчас архитектурой занимаются совсем не те люди, что при проектировании первой версии Magento. И чего дальше? Сейчас выпустят версию 2, народ упрется в те ограничения, которые я описал, и начнут форкать эту новую версию, создавать свои Ентерпризы. Зачем? Там достаточно много здравых идей, но некоторые меня просто в ступор вгоняют…

 
Magento Community Magento Community
Magento Community
Magento Community
 
Sergiy Stotskiy
Member
 
Avatar
Total Posts:  53
Joined:  2011-02-27
 

Главное интерфейс, а EAV - это уже реализация. Если будет интерфейс для создания атрибутов, а они не будут в базе хранится как в EAV структуре, тогда какая разница есть EAV или нет?:)

 
Magento Community Magento Community
Magento Community
Magento Community
 
ArtArtArt
Sr. Member
 
Total Posts:  166
Joined:  2010-02-02
 

Гм… А как организуешь интерфейс, при другой структуре базы? С возможностью фильтровать коллекцию по значениям атрибутов и неограниченным (условно) количеством наборов атрибутов? Или Ð’Ñ‹ думаете, что интерфейс организуется магическим путем, потому что там (у разработчиков Magento) сплошные гуру? Смею заверить, обычные люди. Не будет EAV - не будет нормальной работы с атрибутами.

 
Magento Community Magento Community
Magento Community
Magento Community
 
ArtArtArt
Sr. Member
 
Total Posts:  166
Joined:  2010-02-02
 

Кстати, про local code pool что-то тоже нигде информации нет, так же как и про компиляцию, но в новой версии на github их действительно нет. Странный какой-то апгрейд, через шаг назад. Я сейчас могу время отклика сервера (генерацию страницы) довести до 0.2 сек (не полностраничное кэширование), на средней VPS, без компиляции так не получится. Вроде девиз - ускорение движка, а как то наоборот выходит. Сервер должен будет инклюдить каждый файл по отдельности, а там их много. И никакие кэшеры опкода не помогут. Тоже и с local code pool. Как править ошибки ядра, без переписывание файлов ядра - непонятно. Вроде хотят упростить проект, но что может быть проще, чем скопировать файл в local code pool и поправить? Никаких модулей писать не надо, не надо разбираться с конфигами. В общем, странные, несбалансированные решения, под соусом движения к совершенству.

 
Magento Community Magento Community
Magento Community
Magento Community
 
Sergiy Stotskiy
Member
 
Avatar
Total Posts:  53
Joined:  2011-02-27
 
ArtArtArt - 08 June 2012 10:33 PM

Кстати, про local code pool что-то тоже нигде информации нет, так же как и про компиляцию, но в новой версии на github их действительно нет. Странный какой-то апгрейд, через шаг назад. Я сейчас могу время отклика сервера (генерацию страницы) довести до 0.2 сек (не полностраничное кэширование), на средней VPS, без компиляции так не получится. Вроде девиз - ускорение движка, а как то наоборот выходит. Сервер должен будет инклюдить каждый файл по отдельности, а там их много. И никакие кэшеры опкода не помогут. Тоже и с local code pool. Как править ошибки ядра, без переписывание файлов ядра - непонятно. Вроде хотят упростить проект, но что может быть проще, чем скопировать файл в local code pool и поправить? Никаких модулей писать не надо, не надо разбираться с конфигами. В общем, странные, несбалансированные решения, под соусом движения к совершенству.

На счет интерфейса EAV - он уже 100500 лет как есть. EAV - это всего навсего способ хранения данных. Данные можно хранить в плоской таблице, а атрибутами будут ее поля, что вполне нормально ибо структура базы данных обычно не меняется (и не должна менятся) после того как программист все настроил и запустил. И вообще откуда информация, что EAV кто-то хочет убрать? На сколько я знаю его просто пересмотрят и где-то (может) что-то зарефакторят. Так что будьте спокойны господа.

На счет code pool, кто сказал что его нет? Каталога нет, но это не значит что его нельзя создать=) Смотрите исходники внимательно (app/boostrap.php):

Mage::register('original_include_path'get_include_path());

$paths[] BP DS 'app' DS 'code' DS 'local';
$paths[] BP DS 'app' DS 'code' DS 'community';
$paths[] BP DS 'app' DS 'code' DS 'core';
$paths[] BP DS 'lib';
Magento_Autoload::getInstance()->addIncludePath($paths);

Кому интересно Magento2 можно почитать на http://alanstorm.com об основных изменениях.

 
Magento Community Magento Community
Magento Community
Magento Community
 
ArtArtArt
Sr. Member
 
Total Posts:  166
Joined:  2010-02-02
 
sergiy_stotskiy - 08 June 2012 11:10 PM

На счет интерфейса EAV - он уже 100500 лет как есть. EAV - это всего навсего способ хранения данных. Данные можно хранить в плоской таблице, а атрибутами будут ее поля, что вполне нормально ибо структура базы данных обычно не меняется (и не должна менятся) после того как программист все настроил и запустил. И вообще откуда информация, что EAV кто-то хочет убрать? На сколько я знаю его просто пересмотрят и где-то (может) что-то зарефакторят. Так что будьте спокойны господа.

Вы, просто, наверное, не в теме, про возможности работы Magento с атрибутами товара, а так же, при помощи небольших телодвижений, пользователя и каталога. EAV добавляет возможность настраивать атрибуты товара, пользователя, каталога без изменения схемы БД. В общем, почитайте документацию и посмотрите код.

Насчет local code pool. Да, можно добавить папку вручную. Но, почему ее просто не оставить.  А компиляция как? Все-таки, на Zend Framework система основана, плюс у самой много классов, и каждый в отдельном файле.

 
Magento Community Magento Community
Magento Community
Magento Community
 
Sergiy Stotskiy
Member
 
Avatar
Total Posts:  53
Joined:  2011-02-27
 
ArtArtArt - 09 June 2012 02:30 PM

sergiy_stotskiy - 08 June 2012 11:10 PM
На счет интерфейса EAV - он уже 100500 лет как есть. EAV - это всего навсего способ хранения данных. Данные можно хранить в плоской таблице, а атрибутами будут ее поля, что вполне нормально ибо структура базы данных обычно не меняется (и не должна менятся) после того как программист все настроил и запустил. И вообще откуда информация, что EAV кто-то хочет убрать? На сколько я знаю его просто пересмотрят и где-то (может) что-то зарефакторят. Так что будьте спокойны господа.

Вы, просто, наверное, не в теме, про возможности работы Magento с атрибутами товара, а так же, при помощи небольших телодвижений, пользователя и каталога. EAV добавляет возможность настраивать атрибуты товара, пользователя, каталога без изменения схемы БД. В общем, почитайте документацию и посмотрите код.

Насчет local code pool. Да, можно добавить папку вручную. Но, почему ее просто не оставить.  А компиляция как? Все-таки, на Zend Framework система основана, плюс у самой много классов, и каждый в отдельном файле.

И почему все здесь на форуме гуру… EAV. Правильная архитектура приложения - это взаимодействие всех участников (объектов) через интерфейсы. Часто реализуемые такие взаимодействия назвали шаблонами проектирования (или паттернами). Раньше в Magento не было индексаторов (Ñ‚.е. плоских таблиц для EAV). Их добавили, при этом интерфейс остался тотже (за исключением добавления новых методов, которые не влияют на обратную совместимость). И Вам не нужно делать в коде никаких лишних телодвижений когда Ð’Ñ‹ вызываете коллекцию продуктов ибо этот объект сам реализовывает логику, которая указывает ему обращаться к EAV таблицам или к плоским.

Директорию удалили очень даже правильно ибо пустая директория в дистрибутиве (WTF? был бы я начинающим magento программистом я бы никогда не догадался зачем она, т.е. нужно читать документацию, в которой, может быть, белым по-черному будет написано, что такое code pool и что локал пул нужно создать руками). А на счет компилятора, если его удалили значит он стал не нужным ибо нужно читать оф. доки (так же можно постить фичи и баги на GITHUB, если кто вдруг не знает):

Magento_Autoload class mapping is an alternative to the Mage_Compiler module and the discontinued “compiler” feature of the Magento framework.

 
Magento Community Magento Community
Magento Community
Magento Community
 
ArtArtArt
Sr. Member
 
Total Posts:  166
Joined:  2010-02-02
 

Ну, почему же сразу гуру… Я себя так не позиционирую.
1. Насчет интерфейсов и паттернов (красивое слово grin ). Интерфейс - это просто описания метода (или методов), не более. Если модель данных позволяет добавлять атрибуты к сущности, без изменения схемы БД, то можно продекларировать метод addAttribute(), это я условно. А вот если не позволяет - то что декларировать - то? Про запись всех атрибутов в плоскую таблицу - Вы, наверное, просто не работали с магазинами с большой и разнообразной номенклатурой, там индексацию product_flat отключать приходится. Почему? А Вы подумайте.
2. Мы здесь обсуждаем Magento 2. Кто и что посчитает нужным написать насчет баг и фич на github, напишет, наверное. Есть ли что сказать по существу, без мнений, что раз сделали - значит надо? Ну, или напишите, кому и зачем надо, какие, по Вашему мнению плюсы и минусы. Содержательный ответ, в общем. Может я зря насчет компилятора… Может Ð’Ñ‹ знаете как надо. Что за Magento_Autoload такой - новый? Как он позволит за один инклюд пару сотен классов загрузить? Расскажите, пожалуйста!

 
Magento Community Magento Community
Magento Community
Magento Community
 
Sergiy Stotskiy
Member
 
Avatar
Total Posts:  53
Joined:  2011-02-27
 
ArtArtArt - 13 June 2012 10:16 AM

Ну, почему же сразу гуру… Я себя так не позиционирую.
1. Насчет интерфейсов и паттернов (красивое слово grin ). Интерфейс - это просто описания метода (или методов), не более. Если модель данных позволяет добавлять атрибуты к сущности, без изменения схемы БД, то можно продекларировать метод addAttribute(), это я условно. А вот если не позволяет - то что декларировать - то? Про запись всех атрибутов в плоскую таблицу - Вы, наверное, просто не работали с магазинами с большой и разнообразной номенклатурой, там индексацию product_flat отключать приходится. Почему? А Вы подумайте.
2. Мы здесь обсуждаем Magento 2. Кто и что посчитает нужным написать насчет баг и фич на github, напишет, наверное. Есть ли что сказать по существу, без мнений, что раз сделали - значит надо? Ну, или напишите, кому и зачем надо, какие, по Вашему мнению плюсы и минусы. Содержательный ответ, в общем. Может я зря насчет компилятора… Может Ð’Ñ‹ знаете как надо. Что за Magento_Autoload такой - новый? Как он позволит за один инклюд пару сотен классов загрузить? Расскажите, пожалуйста!

Magento_Autoload - загрузчик классов в Magento2. Class mapping - хэш с помощью, которого можно указать в каком файле какой класс искать. Положите все классы в один файл и укажите в маппинге брать все классы из одного файла.
Тема вроде зачем и почему - это холивар ибо то, что Вы спрашиваете есть в оф. доках, при чем открытых. Также Alan Storm делает обзор интересных возможностей Magento2.

Можно продекларировать метод addAttribute даже если этот метод вносит изменения в схему базы дынных. Так как интерфейс для Вас всего лишь описание метода, то понятно, что Вы не писали в ООП стили на языках со статической типизацией переменных и не понимаете сути интерфейсов. ORM для того и пишется, чтобы предоставить интерфейс клиенту, без знания внутренней реализации самих методов.

 
Magento Community Magento Community
Magento Community
Magento Community
 
Rugento
Guru
 
Avatar
Total Posts:  540
Joined:  2008-11-15
Russia, Vologda
 

Мы тут вообще ничего не понимаем gringringrin
И ООП в первый раз видим))
Компилятор, вроде, и нужен чтобы собрать все файлы в один, а после этого можно использовать маппинг.

 
Magento Community Magento Community
Magento Community
Magento Community
Magento Community
Magento Community
Back to top
Page 1 of 2