народ, кто-нить делал такое, чтобы в элементе индексировались поисковые слова из текстов связанных с ним элементов?

Обработчик и дело в шляпе)

народ, кто-нить делал такое, чтобы в элементе индексировались поисковые слова из текстов связанных с ним элементов?

На событие индексации садишься и хоть с Гугла допданные запрашивай

Обработчик и дело в шляпе)

<врчун>так каждый может</ворчун>

Ахаха, почему не годится?

Лень

<врчун>так каждый может</ворчун>

Есть другой вариант, платишь мне 100 млн и он у тебя сам появляется. Поверь -так уже может не каждый??

Это да, причина

Я про лень

Сделаю за 10 млн

10 млн. - это достаточное лекарство от лени )))

за 10 лямов я вручную поисковый индекс наберу в ноутпаде

Сделаю за 10 млн

а вот демпинговать нехорошо... и вообще - я могу представить человека который 10 лямов выложит, так возможно не каждый сможет, но вероятность имеется а вот 100лямов за такую глупость - он будет уже стопудово уникален и сможет сказать - вот так не сможет никто :)

за 10 лямов я вручную поисковый индекс наберу в ноутпаде

поисковый индекс на интернет ты хотел сказать? ?

поисковый индекс для собственного поиска битрикса

слабенько.. яж еще только цифры озвучил, а вот валюту еще нет ) так что как знать-как знать)

Да, так получается, что 130 тр и правда мелкая зп, ахах

Let's holy war begin!!!

Вопрос на засыпку. Что делать, если нужна сортировка по св-ву связанного элемента иблока, связанного элемента иблока. То есть связь третьего уровня. Например: Есть иблоки: товары, бренды и поставщики. У поставщиков есть свво "город". У товаров есть свво бренд(привязка), а у брендов есть свво поставщик(привязка). А задача отсортировать товары по городам поставщиков. Как это сделать?

Вопрос на засыпку. Что делать, если нужна сортировка по св-ву связанного элемента иблока, связанного элемента иблока. То есть связь третьего уровня. Например: Есть иблоки: товары, бренды и поставщики. У поставщиков есть свво "город". У товаров есть свво бренд(привязка), а у брендов есть свво поставщик(привязка). А задача отсортировать товары по городам поставщиков. Как это сделать?

ОРМ

Пример кода

сначала ОРМ объекты делаешь для bx_element_property_sXXX потом джоинишь их в секции runtime и сортируй фильтруй как хош

а для этого селекта собрать просто sql совсем-совсем нельзя? и предварительный перерасчет сделать нельзя единоразово, надо именно несколько таблиц тянуть штатными не очень быстрыми методами? хм

Джоны и раньайм - убьют весь Хайлоад на месте

Просто скул можно, но это на крайняк. Опять же Джоны.

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

Джоны и раньайм - убьют весь Хайлоад на месте

сфигали? наоборот. Запрос через CIblockElement сделает на 100500 джоинов больше

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

Это црм - кеш долго не будет жить

сфигали? наоборот. Запрос через CIblockElement сделает на 100500 джоинов больше

для справки - любая орм сущность - селект банальный в два раза дольше будет выполняться (в первую очередь за счет того что несколько раз структуру таблиц поднимает) - дольше чем банальный ciblockelement::getlist даже с указанными пропами

Это црм - кеш долго не будет жить

тогда правильный sql и нормальные ключи проставить, чтобы фуллскана нигде не было при фильтре

если таковой есть.. и будет норм

для справки - любая орм сущность - селект банальный в два раза дольше будет выполняться (в первую очередь за счет того что несколько раз структуру таблиц поднимает) - дольше чем банальный ciblockelement::getlist даже с указанными пропами

"несколько раз структуру таблиц поднимает" а вот отсюда поподробней

На апи получается такого не сделать?

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

На апи получается такого не сделать?

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

ОРМ

Можно пример кода для запуска такой сортировки (не самой орм сущности) ?

"несколько раз структуру таблиц поднимает" а вот отсюда поподробней

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

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

Да не, какие там компоненты битрикса) все свое)

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

А зачем тогда описывать структуру вручную?

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

А, там можно ран таймы например добивать и тд. Ну ок.

И чем кончилось?)

А зачем тогда описывать структуру вручную?

для того чтобы дать доп.данные которых нет в структуре обязательность, валидаторы и т.п. а вот сверка что поле действительно есть, и что оно действительно string а не date - проверка будет

Можно пример кода для запуска такой сортировки (не самой орм сущности) ?

$q = Blank\ReminderPersonalTable::getList( array( 'select' => array( 'ID', 'DATE_DIRECTION_SHORT', 'BLANK_ID', 'BLANK_CODE' => 'E_BLANK.CODE', 'BLANK_NAME' => 'E_BLANK.NAME', 'SPECIALIST_ID', 'SPECIALIST_FIRST_NAME' => 'S_SPECIALIST.FIRST_NAME', 'SPECIALIST_SECOND_NAME' => 'S_SPECIALIST.SECOND_NAME', 'SPECIALIST_LAST_NAME' => 'S_SPECIALIST.LAST_NAME', 'SEND_COUNTER', 'SEND_RESULT' ), 'runtime' => array( new Entity\ReferenceField( 'E_BLANK', 'Bars46\Requests\Blank\BlankList', array('=this.BLANK_ID' => 'ref.ID'), array('join_type' => 'LEFT') ), new Entity\ReferenceField( 'S_SPECIALIST', 'Bars46\Requests\Specialist\SpecialistsListS', array('=this.SPECIALIST_ID' => 'ref.ID'), array('join_type' => 'LEFT') ) ), 'filter' => array( '=ACTIVE' => 'Y', '=CARD_EXECUTOR_ID' => $cardExecutorID ), 'order' => array( 'ID' ) ) );

И чем кончилось?)

собственным модулем, со своим апи, под которым голый sql в нагруженных местах и все жили долго и счастливо, да :)

так а св-ва разбили по таблицам?

естественно, иначе никак

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

странно. Сижу постоянно мониторю query log. не сталкивался с постоянным поднятием полей. может hiload так делает?

на каждую группу товаров свой набор в наборах от заказчика еще скопился мусор различных свойств в общей сложности тысяча, битрикс чебурахнулся бы )

странно. Сижу постоянно мониторю query log. не сталкивался с постоянным поднятием полей. может hiload так делает?

нет, свои таблицы, а на них орм, как дядя битрикс прописал но я не логи смотрел, я танком под нагрузку клал без кешей, а потом глядел что тормозит и устраивает ли меня это

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

причем таблицы примитивные - группа свойств, название свойств, значение свойств надо было поднять связку по id товара, собрать массивчег

Я у себя наоборот прирост скорости видел. Апишный ГетЛист делает запрос прав, запрос полей, запрос пользовательских полей, запрос документооборота и т.д. потом уже делает запрос с тем же джоином

$q = Blank\ReminderPersonalTable::getList( array( 'select' => array( 'ID', 'DATE_DIRECTION_SHORT', 'BLANK_ID', 'BLANK_CODE' => 'E_BLANK.CODE', 'BLANK_NAME' => 'E_BLANK.NAME', 'SPECIALIST_ID', 'SPECIALIST_FIRST_NAME' => 'S_SPECIALIST.FIRST_NAME', 'SPECIALIST_SECOND_NAME' => 'S_SPECIALIST.SECOND_NAME', 'SPECIALIST_LAST_NAME' => 'S_SPECIALIST.LAST_NAME', 'SEND_COUNTER', 'SEND_RESULT' ), 'runtime' => array( new Entity\ReferenceField( 'E_BLANK', 'Bars46\Requests\Blank\BlankList', array('=this.BLANK_ID' => 'ref.ID'), array('join_type' => 'LEFT') ), new Entity\ReferenceField( 'S_SPECIALIST', 'Bars46\Requests\Specialist\SpecialistsListS', array('=this.SPECIALIST_ID' => 'ref.ID'), array('join_type' => 'LEFT') ) ), 'filter' => array( '=ACTIVE' => 'Y', '=CARD_EXECUTOR_ID' => $cardExecutorID ), 'order' => array( 'ID' ) ) );

это не то: - тут две напрямую связанные сущности - нет сортировки вообще по связаному полю)

Я у себя наоборот прирост скорости видел. Апишный ГетЛист делает запрос прав, запрос полей, запрос пользовательских полей, запрос документооборота и т.д. потом уже делает запрос с тем же джоином

Разве это делает гетлист? Ты с компонентой не путаешь?

это не то: - тут две напрямую связанные сущности - нет сортировки вообще по связаному полю)

так по любому из них можно сортировать. типа 'S_SPECIALIST.IBLOCK_ELEMENT_ID. => 'ASC'

это да

поэтому был смайлик

суть в первом пункте

Разве это делает гетлист? Ты с компонентой не путаешь?

а компонента не гетлист использует типа?

забейте на компонент

про него вообще не было речи)

а компонента не гетлист использует типа?

А из компоненты это можно вырезать. Апи и компоненту со всем фаршем сравнивать не корректно

Я сравнивал апи и апи

да, давайте не ухдоить от темы)

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

ERROR: S client not available

вау вау, хорошо сказано

да, давайте не ухдоить от темы)

Не мешай флудить, твоя проблема вторична ?

ахаха

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

Чистый нет лист не проверяет права насколько помню. Документооборот лучше на нагруженных выключать. Not null никогда не ляжет в ключ по определению.

документооборот у меня вообще как модуль отключен. однако в запросах WF_ постоянно пытается найти

Не надо, я пошутил. Ты всегда прав, мастер. )

ща проведем бесчеловечный эксперимент

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

гетлист не проверяет сам права

и WF там правда зашит

есть еще вопрос интересный, если мы с этим закончили?)

ща проведем бесчеловечный эксперимент

давай, ждем результатов

Запрос вида $rsAuthors = CIBlockElement::GetList( array("NAME" => "ASC"), array("IBLOCK_ID" => 17), false, false, array("ID","PROPERTY_TR_EMAIL") ); вызвал.... только не баньте за лог ))))

ТУТ был длинный лог из 17 запросов. стер, чтобы ленту не засорять

ТУТ был длинный лог из 17 запросов. стер, чтобы ленту не засорять

Да размер запроса вторичен. Что explain показывает?

explain какого из 17 запросов?

А блин. Я на телефон перепрыгнул. Думал ты размером решил поразить) сорри

а через ОРМ запрос был бы 1

всего -то надо было получить ИД и строчку с емайлом )))

Размер и количество запросов не так важны на самом деле)

Если запросов не тысяча?

а через ОРМ запрос был бы 1

как это там был бы один запрос? св-ва же в отдельной таблице?

может еще эксперимент?

runtime и был бы один запрос приджоиненной таблицей свойств

щас сделаем

а, ну с джоинами - ок. давай, ждем лог)

Размер и количество запросов не так важны на самом деле)

если мало данных и мелкая посещаемость (активность) проекта - вообще ничего не важно))

Ну это да, но вообще важны ключи

План запроса опять же