WebAsyst - "красивые запросы" или что с этим всем делать

Тема в разделе "WebAsyst", создана пользователем Slaviq, 1 окт 2009.

Модераторы: mdss
  1. Slaviq

    Slaviq Создатель

    Регистр.:
    19 сен 2007
    Сообщения:
    37
    Симпатии:
    1
    Сегодня в ночь решил же ж посмотреть почему при нажатии на кнопочку Расширеного поиска ДебагТайм составляет 16 - 45 секунд.
    Уточню в базе товаров >35к, категорий >5к

    Включил логирование запросов мускула, на страничке из генераторов форм ничего не оставил ....
    В результате после запуска по линку поиска получил log - фал весом 1.6 Мега!!!

    Из этого файла 95% заняли запросы по типу по каждой категории (подкатегории) получить вложенную категорию, подкатегорию в массив и получить параметры для выбора, количество товаров ... Это делается по каждой категории!!! а потом выбираются по каждой полученной категории подкатегории!!! Карочи брэд ...

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

    Сегодня буду сидеть разбираться ... думаю все это переписать нафик. Благо за плечами знаний предостаточно, было б время.

    Товарищи, если кто уже занимался разбором полетов, давайте сработаемся, и родим народу нормальный вариант поисковой машины. Кто что может ценного рассказать ... милости прошу в этот топик, личку, аську, жталк ...
    Сегодня начинаю расколупывателно поступательные движения.
     
  2. NeoGayver

    NeoGayver

    Регистр.:
    27 авг 2008
    Сообщения:
    225
    Симпатии:
    83
    Смысла в этом нету так как возиться с таким мусором который понаписали в WebAsyst это тратить лишнее время! Лучше и проще будет написать свой двиг с нуля!
     
  3. Slaviq

    Slaviq Создатель

    Регистр.:
    19 сен 2007
    Сообщения:
    37
    Симпатии:
    1
    Думаю что с подобными прибамбасами это будет долше :)
    Как говорили наши дедушки и бабушки- "мы не ищем легких путей"
    Уже просто потрачено время на организацию магазина на мега пупер движке. Так что пути назад особенно нету.

    Тем более если сделать по человечески то мож хоть в следующих версиях разработчики будут более ответственными
     
  4. Welho®

    Welho® Предвестник пьянки

    Регистр.:
    4 дек 2007
    Сообщения:
    855
    Симпатии:
    331
    да разработчик по большому счету клал на все, у него покупают вебасист и нормально, поверь код править не станут и корявых запросов меньше не станет, потому как там, судя по всему, работает над кодом куча людей, которые всю работу над проектом ведут несогласованно, то есть такое ощущение, что нет некоего координатора и клепают "куски" шопа разные люди, которые не в курсе что делают остальные участники.
    Тому подтверждение те же неоднократно повторяющиеся запросы и тому подобный бред.
    Исправлять это никто не станет, опять-таки, взять тот же самый пресловутый Shop-script, который фактически является предшественником вебасиста, так в нем такого же гамна не меньше, в чем может убедиться любой желающий, благо там даже не зашифровано нихрена

    к тому же, все твои потуги в плане убрки мусорных запросов сведутся либо к застопориванию на одной версии скрипта или снесутся после установки очередного мегаобновления до некой 2.8.X
     
  5. Slaviq

    Slaviq Создатель

    Регистр.:
    19 сен 2007
    Сообщения:
    37
    Симпатии:
    1
    Пока планирую застопорится на "некой 2.8.X", в дальнейшем буду думать :)
    Если такие мегаобновления как у них были, то это все можно ставить в ручную используя сравнительный анализ

    ... все это не потеме, и так понятно, давайте ветку развивать в русле как поправить, а не ВебАсист - мусор/лучше использовать что то другое, это можно написать и в ветке "Какой лучше движок использовать"
     
  6. Welho®

    Welho® Предвестник пьянки

    Регистр.:
    4 дек 2007
    Сообщения:
    855
    Симпатии:
    331
    Я не предлагал использовать что-то другое, я только утверждаю что правка того что есть это "Сизифов труд"
    То что на первый взгляд вам показалось бредом это цветочки по сравнению с тем что предстоит.
    Eсли углубиться дальше, то фактически процентов 70 того что имеется, можно(читай нужно) переписать намного проще и не в ущерб функционалу, а после таких изменений вам никакое сравнение с вновь вышедшими версиями не светит, потому что в дальнейшем самым здравым решением будет наращивание собственного функционала нежели смотреть на то что там оф. разрабы выдадут.


    p.s. не нужно отвечать на мой пост, загляни в личку, пообщаемся, а потом хоть самолет из WA стройте ))
     
  7. Slaviq

    Slaviq Создатель

    Регистр.:
    19 сен 2007
    Сообщения:
    37
    Симпатии:
    1
    в принципе так и хочу
    ... правка того что есть это "Сизифов труд" ...
    так сложилось что уже назад пути нету

    потому и собираюсь сделать и выложить тут решение для таких же людей, которые повелись на красивую обертку и простоту настройки, а теперь на них жалуются хостеры или на людей жалуются клиенты с претензиями - тормозит поиск

    переписывать уже нет времени - нужно работать
    переходить на новый двиг можно - но нет столько времени: дизайн, перенос каталога, разные доработки ....

    так что предлагаю выкладывать конкретные предложения по существу
     
  8. Slaviq

    Slaviq Создатель

    Регистр.:
    19 сен 2007
    Сообщения:
    37
    Симпатии:
    1
    Вобщем много чего комментировал
    страница теперь генериццо 0.3-1 сек в зависимости от времени суток :)
    1. что сделал основного, так это NESTED SET:
    PHP:
    <?
    $db_host     "127.0.0.1";
    $db_user     "root";
    $db_password "";
    $db_name     'mybase';
    $table 'sc_categories';
    $number 1;
    make_nested(0);
    /*function make_nested($parent_id = 0) {
        global $db, $table, $number;
        $c = $db->selectCell("SELECT COUNT(*) from ".$table." \
        where parent=".$parent_id."");
        for($i=0; $i<$c; $i++) {
            $newrow = $db->selectRow("SELECT * FROM ".$table." \
            where parent=".$parent_id." order by name_ru, categoryID \
            LIMIT $i, 1");
            $db->query("UPDATE `".$table."` SET lft=".$number." \
            WHERE categoryID=".$newrow['categoryID']."");
            $number++;
            make_nested($newrow['id']);
            $db->query("UPDATE `".$table."` SET rght=".$number." \
            WHERE categoryID=".$newrow['categoryID']."");
            $number++;
        }
    }*/
    function SQL($query) {
       global 
    $db_host$db_user$db_password$db_name$dbh;
       if (! 
    $dbh) {
          
    $dbh mysql_connect($db_host$db_user$db_password);
          
    mysql_select_db($db_name);
       }
       
    mysql_query ("SET NAMES `cp1251`");   
       
    $sth mysql_query($query); #mysql_query $db_name
       
    if (mysql_errno()>0) {
            echo(
    mysql_errno()." : ".mysql_error()."<BR>\r\n $query<br>");
            die(
    "Error in sql");
            exit;
       }
       return 
    $sth;
    }
    function 
    make_nested($parent_id 0) {
        global 
    $table$number;
        if (
    $parent_id == 0)
        { 
    $where =" where parent is null";} 
        else {
    $where =" where parent=".$parent_id;}
        
    $c SQL("SELECT * from ".$table." ".$where);
        
    $i=0;
        while (
    $newrow mysql_fetch_array($c)) {
            
    SQL("UPDATE `".$table."` SET lft=".$number." WHERE categoryID=".$newrow['categoryID']."");
            
    $number++;
            
    make_nested($newrow['categoryID']);
            
    SQL("UPDATE `".$table."` SET rght=".$number." WHERE categoryID=".$newrow['categoryID']."");
            
    $number++;
        }
    }
    ?>
    2.файлы category_functions.php и product_functions.php соответственно что нашел связанное с работой цикла для получени категорий и подкатегорий переписал на лаконичный (пипец умники, как такое можно писать?!)
    получилось что то вроде этого:
    PHP:
        $q db_query("select lft, rght from SC_categories sc where categoryId = ".$categoryID);
        while( 
    $row=db_fetch_row($q) ){
            
    $sclft $row["lft"];
            
    $scrght $row["rght"];
        }    
        
    $sql_category_part " sc.lft >= ".$sclft." and sc.rght <= ".$scrght;
    3. дальше делал апдейт
    PHP:
    update `SC_product_options_valuess
    set 
    `variantID` = (select variantId 
           from   
    `SC_products_opt_val_variantsc
          where s
    .optionID c.optionID
              
    and c.option_value_ru replaces.option_value_ru)
    это имеется в виду для всех характеристик прописываем ИДшники!!!
    ЧТОБЫ НЕ ДЕЛАТЬ ЛЕФТ ДЖОИНЫ!
    4. в _prepareSearchExtraParameters($template){
    переписал все на:
    PHP:
    function _prepareSearchExtraParameters($template){
        
    $sqls_joins = array();
        
    $sqls_options = array();
        
    $categoryID $template['categoryID'];
        
    $sqls_params = array();
        
    $cnt 0;
        
    $_count 0;
        
    $sqls_options[] = '
                    1=1
                '
    ;
        foreach( 
    $template as $key => $item ){
            if(!isset(
    $item['optionID']))continue;
            if(
    $item['value'] === '')continue;
            if(
    $key === 'categoryID' )continue;
            
    // get value to search
            
    $res schOptionIsSetToSearch$categoryID$item['optionID'] );
            if(
    $res['set_arbitrarily'] && $item['value'] === '0')continue;
            
    $sqls_joins[] = '
                JOIN ?#PRODUCT_OPTIONS_VALUES_TABLE PrdOptVal'
    .$cnt.'
                  ON p.productID = PrdOptVal'
    .$cnt.'.productID 
                   AND PrdOptVal'
    .$cnt.'.optionID='.intval($item['optionID']).
                   AND PrdOptVal'
    .$cnt.'.variantID='.intval($item['value']).'                   
                  '
    ;    
            
    $cnt++;
        }
        return array(
    'where' => $sqls_options'join' => $sqls_joins'params'=>$sqls_params);
    }
    вместо всех благоглупостей что там написаны
    кому нужно искать по названию ... обыгрывайте сами :) мне не нужно.
    Вобщем если Вы не поняли и половины из того что здесь написано ... не пытайтесь ничего делать ... только поломаете все к такой то бабушке
    если вы поняли больше половины ... то дописать под свои нужды не сотавит труда :)
    надеюсь кому то пригодится такое решение. Успехов!
     
    Crazy_Serg нравится это.
  9. Crazy_Serg

    Crazy_Serg Постоялец

    Регистр.:
    13 сен 2009
    Сообщения:
    83
    Симпатии:
    16
    PHP:
    update `SC_product_options_valuess
    set 
    `variantID` = (select variantId 
           from   
    `SC_products_opt_val_variantsc
          where s
    .optionID c.optionID
              
    and c.option_value_ru replaces.option_value_ru)
    это имеется в виду для всех характеристик прописываем ИДшники!!!
    ЧТОБЫ НЕ ДЕЛАТЬ ЛЕФТ ДЖОИНЫ!
    [/QUOTE]
    Опечатка вместо replaces.option_value_ru нужно s.option_value_ru
    PHP:
    update `SC_product_options_valuess
    set 
    `variantID` = (select variantId 
           from   
    `SC_products_opt_val_variantsc
          where s
    .optionID c.optionID
              
    and c.option_value_ru s.option_value_ru)
    К сожалению работает только для одного языка,
    Хотя если добавить variantID Для каждого языка, может существенно помочь
    вообще мультиязычность реализовывать добавлением полей в таблицу достаточно удобное для программистов, но очень спорное решение, но я не сильно смотрел другие магазиный. но мне поддержка шаблонов и конфигуратор пока попалась только здесь
     
  10. Slaviq

    Slaviq Создатель

    Регистр.:
    19 сен 2007
    Сообщения:
    37
    Симпатии:
    1
    многоязычность в предлженном варианте работает!
    SC_product_options_values просто нужно проинициализировать ИДшниками
    конкретных характеристик
    в advanset_search выводятся option_value_ru, option_value_en и так далее в зависимости от выбранного языка, но они завязаны !на 1н ИДшник! который записан уже (апдейтом выше) в SC_product_options_values