$arSelect = Array("ID", "IBLOCK_ID", "NAME", "DETAIL_PAGE_URL", "PREVIEW_PICTURE", "DETAIL_PICTURE", "CATALOG_GROUP_7", "PROPERTY_CML2_ARTICLE");
$arFilter = Array("IBLOCK_ID"=>$GLOBALS['CATALOG_IBLOCK_ID'],
"ACTIVE"=>"Y",
"ACTIVE_DATE"=>"Y",
"?PROPERTY_CML2_ARTICLE"=>$acat,);
$res = CIBlockElement::GetList(Array(),$arFilter,false,false,$arSelect);
Предложение касается строки фильтра: "?PROPERTY_CML2_ARTICLE"=>$acat
При помощи этого фильтра отфильтруются элементы, у которых $acat является подстрокой строки "PROPERTY_CML2_ARTICLE".
А отфильтровать в другом направлении, чтобы значения "PROPERTY_CML2_ARTICLE" могли быть подстроками $acat невозможно.
Предлагаю добавить эту возможность.
$arFilter = Array("IBLOCK_ID"=>$GLOBALS['CATALOG_IBLOCK_ID'],
"ACTIVE"=>"Y",
"ACTIVE_DATE"=>"Y",
"?PROPERTY_CML2_ARTICLE"=>$acat,);
$res = CIBlockElement::GetList(Array(),$arFilter,false,false,$arSelect);
Предложение касается строки фильтра: "?PROPERTY_CML2_ARTICLE"=>$acat
При помощи этого фильтра отфильтруются элементы, у которых $acat является подстрокой строки "PROPERTY_CML2_ARTICLE".
А отфильтровать в другом направлении, чтобы значения "PROPERTY_CML2_ARTICLE" могли быть подстроками $acat невозможно.
Предлагаю добавить эту возможность.
В нестандартных случаях (например, написание API) очень часто требуется обычный лимит, как используется базах данных, например, вот так:
Чтобы сделать такую возможность для разработчиков, впринципе, достаточно заменить код:
следующим
ну и дополнить документацию
SEL ECT * FR OM `b_iblock_element` LIMIT 30 , 30 |
if (!empty( $arNavStartParams ) && is_array ( $arNavStartParams )) { |
if (!empty($arNavStartParams['limitStart']) && !empty($arNavStartParams['limitCount'])){
$strSql = "
SELECT ".$el->sSelect."
FR OM ".$el->sFrom."
WH ERE 1=1 ".$el->sWhere."
".$el->sGroupBy."
".$el->sOrderBy."
LIMIT ".intval ($arNavStartParams['limitStart']).", ".intval ($arNavStartParams['limitCount'])."
";
$res = $DB->Query ( $strSql,
false,
"FILE: ".__FILE__."<br> LINE: ".__LINE__
);
} elseif (!empty( $arNavStartParams ) && is_array ( $arNavStartParams )) { |
ну и дополнить документацию
В параметре фильтр метода CBXShortUri::GetList() не хватает возможности получать выгребку для массива идентификаторов (поле id): приходится делать вызов метода в цикле.
Суть проблемы - нельзя сгруппировать элементы по полю с сортировкой отличной от этого поля. Проще говоря: сейчас даже при указании параметра arGroupBy в него добавятся все поля из параметра arSortBy и сгруппированы не будут.
Ответил 
Жуков Евгений 09.10.2014 14:31:28
Жуков Евгений 09.10.2014 14:31:28
FAQ:
В сущностях, поддерживающих БП, требуется фильтр для выборки только элементов, по которым у пользователя есть задания.
Поясню, есть какой-нибудь такой список документов (зарезал таблицу, чтоб не перегружать), всего около 5 тысяч. По 30 из них у сотрудника есть задания, но по каким - найти практически невозможно.
Пользоваться списком заданий часто не удобно - он не содержит информации по документам по понятным причинам - это общая сущность, имеющая минимум аналитики, всё, чем можно оперировать - название задания (ограничено 128 знаками) и описание. В них нельзя сделать восприятие информации достаточно структурированным и удобным пользователю.
Тогда как в списке документов конкретного типа всё понятно, отображение нужных колонок настроено пользователем/админом, видно сразу необходимые поля.Хотелось бы просто выставить фильтр - показывать только с заданиями и всё.
Такая реализация часто была бы гораздо удобней списка заданий и заменяла его.
PS. Схожее решение давно есть в инфоблоках, но реализовано только для старых задач на инфоблоках + бп, если кто помнит такие. До сих пор присутствует в коде, хоть и не документировано, так же как и проверки полномочий для бизнес-процессов.
Поясню, есть какой-нибудь такой список документов (зарезал таблицу, чтоб не перегружать), всего около 5 тысяч. По 30 из них у сотрудника есть задания, но по каким - найти практически невозможно.
Пользоваться списком заданий часто не удобно - он не содержит информации по документам по понятным причинам - это общая сущность, имеющая минимум аналитики, всё, чем можно оперировать - название задания (ограничено 128 знаками) и описание. В них нельзя сделать восприятие информации достаточно структурированным и удобным пользователю.
Тогда как в списке документов конкретного типа всё понятно, отображение нужных колонок настроено пользователем/админом, видно сразу необходимые поля.Хотелось бы просто выставить фильтр - показывать только с заданиями и всё.
Такая реализация часто была бы гораздо удобней списка заданий и заменяла его.
PS. Схожее решение давно есть в инфоблоках, но реализовано только для старых задач на инфоблоках + бп, если кто помнит такие. До сих пор присутствует в коде, хоть и не документировано, так же как и проверки полномочий для бизнес-процессов.
Или группу методом GetBy, например так:
Что бы искать элементы инфоблоков по любому стандартному полю, в частности символьному коду.
Тогда не придется городить целый GetList ради выбора единственной записи по символьному коду.
CIBlockElement::GetBy( mixed by, mixed value ); |
Что бы искать элементы инфоблоков по любому стандартному полю, в частности символьному коду.
Тогда не придется городить целый GetList ради выбора единственной записи по символьному коду.
Детальное описание проблемы -
Кратко:
При фильтрации по группе, в CUser::GetList сначала делается подзапрос, выбирающий (почти) все записи из таблицы `b_user_group`. В случае, когда пользователей много, запрос начинает очень сильно тормозить. Если добавить несложную проверку на ID пользователя (при его/их указании), то запрос можно сильно оптимизировать.
Соответственно, предлагаю эту оптимизацию провести.
В ТП мне ответили, что это редкий случай и на все такие случаи оптимизаций не напасешься, но эти изменения затронут именно эту конкретную ситуацию - я не вижу у них побочных эффектов, соответственно и причин их не внести не вижу.
Кратко:
При фильтрации по группе, в CUser::GetList сначала делается подзапрос, выбирающий (почти) все записи из таблицы `b_user_group`. В случае, когда пользователей много, запрос начинает очень сильно тормозить. Если добавить несложную проверку на ID пользователя (при его/их указании), то запрос можно сильно оптимизировать.
Соответственно, предлагаю эту оптимизацию провести.
В ТП мне ответили, что это редкий случай и на все такие случаи оптимизаций не напасешься, но эти изменения затронут именно эту конкретную ситуацию - я не вижу у них побочных эффектов, соответственно и причин их не внести не вижу.
Описывал ранее в блоге () сложности, связанные с работой GetList, если имеется привязка элементов.
Например, справочник Модели [секция - Бренд, элемент - Модель] и каталог Товары [секция - Категория, элемент - Товар] связаны между собой свойством "Привязка к товарам". Мои модификации делают возможными следующий синтаксис:
Все изменения касаются файла /bitrix/modules/iblock/classes/general/iblockelement.php. Версия модуля "Информационные блоки" - 11.0.2. Выложил только модифицированные функции (мои дополнения и модификации выделены цветом):
Например, справочник Модели [секция - Бренд, элемент - Модель] и каталог Товары [секция - Категория, элемент - Товар] связаны между собой свойством "Привязка к товарам". Мои модификации делают возможными следующий синтаксис:
//найти все мужские товары $arFilter["PROPERTY_MODEL.PROPERTY_GENDER"] = $prop1; //найти товары определенного бренда $arFilter["PROPERTY_MODEL.IBLOCK_SECTION_ID"] = $sect1; //посчитать количество кожаных товаров $arGroupBy["PROPERTY_MODEL.PROPERTY_MATERIAL"] = $prop2; //посчитать количество товаров бренда $arGroupBy["PROPERTY_MODEL.IBLOCK_SECTION_ID"] = $sect2; |
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
