Раньше чтоб получить, например, список групп пользователя я мог выполнить запрос
$arUser = \Bitrix\Main\UserTable::getList([
'select' => ['ID', 'LOGIN', 'GROUP_LIST'],
'runtime' => [
new \Bitrix\Main\Entity\ReferenceField(
'GROUP_REF',
\Bitrix\Main\UserGroupTable::getEntity(),
[
'=this.ID' => 'ref.USER_ID'
]
),
new \Bitrix\Main\Entity\ExpressionField(
'GROUP_LIST',
'GROUP_CONCAT(DISTINCT %s SEPARATOR "[#]")',
'GROUP_REF.GROUP_ID',
[
'fetch_data_modification' => function () {
return [
function ($val) {
if (empty($val)) {
return [];
}
return explode("[#]", $val);
}
];
}
]
)
]
])->fetch();
и в $arUser['GROUP_LIST'] был список идентификаторов групп.
В парадигме объектов агрегирующие поля запрещены - при fetchObject бросается исключение "Result of query with aggregation could not be fetched as an object". Хотя если в файле bitrix/modules/main/lib/orm/query/result.php в методе initializeFetchObject закомментировать проверку на наличие в запросе агрегирующих полей [if (!empty($this->query->getGroupChains()))] и ExpressionField'у задать тип ArrayField, то в результате fetchObject прекрасно возвращается поле содержащее массив значений.
Идея: разрешить использование агрегирующих полей, либо доработать АПИ так, чтоб можно было получать нечто подобное без лишних запросов.
$arUser = \Bitrix\Main\UserTable::getList([
'select' => ['ID', 'LOGIN', 'GROUP_LIST'],
'runtime' => [
new \Bitrix\Main\Entity\ReferenceField(
'GROUP_REF',
\Bitrix\Main\UserGroupTable::getEntity(),
[
'=this.ID' => 'ref.USER_ID'
]
),
new \Bitrix\Main\Entity\ExpressionField(
'GROUP_LIST',
'GROUP_CONCAT(DISTINCT %s SEPARATOR "[#]")',
'GROUP_REF.GROUP_ID',
[
'fetch_data_modification' => function () {
return [
function ($val) {
if (empty($val)) {
return [];
}
return explode("[#]", $val);
}
];
}
]
)
]
])->fetch();
и в $arUser['GROUP_LIST'] был список идентификаторов групп.
В парадигме объектов агрегирующие поля запрещены - при fetchObject бросается исключение "Result of query with aggregation could not be fetched as an object". Хотя если в файле bitrix/modules/main/lib/orm/query/result.php в методе initializeFetchObject закомментировать проверку на наличие в запросе агрегирующих полей [if (!empty($this->query->getGroupChains()))] и ExpressionField'у задать тип ArrayField, то в результате fetchObject прекрасно возвращается поле содержащее массив значений.
Идея: разрешить использование агрегирующих полей, либо доработать АПИ так, чтоб можно было получать нечто подобное без лишних запросов.
В связи с тем что внутри метода getList создается новый Query и в итоге возвращается готовый sql запрос, есть невероятная проблема расширения параметров при наследовании DataManager.
Мне вот для sphinx потребовался новый параметр 'match', и чтобы мне туда его засунуть, мне нужно полностью переписать метод getList, т.е. скопипастить все что есть в исходниках этого метода и где-то в серединку добавить 'match'. А должно быть как-то так:
С учетом того что эта функция должна возвращать Result, а не Query, нужно добавить внутри хотя бы один метод, вместо кучи кода обработки параметров, т.е. сделать хотя бы так:
Тогда в метод buildQuery можно будет без проблем добавить любой новый параметр.
А в данный момент нужно именно копипастить код, да и еще в 17 версии появился ключ 'cache', и вот допустим у меня старая версия ядра, и если мне нужен этот ключ 'cache' в моем DataManager для sphinx, уже после обновления, то мне надо опять скопипастить новые исходники.
Мне вот для sphinx потребовался новый параметр 'match', и чтобы мне туда его засунуть, мне нужно полностью переписать метод getList, т.е. скопипастить все что есть в исходниках этого метода и где-то в серединку добавить 'match'. А должно быть как-то так:
public static function getList(array $parameters = [])
{
$query = parent::getList($parameters);
if (isset($parameters['match']))
{
$query->setMatch($parameters['match']);
}
return $query;
} |
С учетом того что эта функция должна возвращать Result, а не Query, нужно добавить внутри хотя бы один метод, вместо кучи кода обработки параметров, т.е. сделать хотя бы так:
public static function getList(array $parameters = [])
{
return static::buildQuery($parameters)->exec();
}
public/*protected?*/ static function buildQuery(array $parameters = [])
{
$query = static::query();
// тут текущий код
return $query;
}
|
Тогда в метод buildQuery можно будет без проблем добавить любой новый параметр.
А в данный момент нужно именно копипастить код, да и еще в 17 версии появился ключ 'cache', и вот допустим у меня старая версия ядра, и если мне нужен этот ключ 'cache' в моем DataManager для sphinx, уже после обновления, то мне надо опять скопипастить новые исходники.
Вся соль в том, что сейчас в методе compileDbTableStructureDump() ORM-сущностей "хардкодом" прописано добавление атрибута NOT NULL всем создаваемым полям.
Здравствуйте! То что появилось проверка заказа перед возможностью оплаты - очень здорово, но не хватает именно флага разрешения оплаты, помимо зависимости от статуса.
Бывает ситуация, когда заказ возвращается в более ранний статус чем тот что разрешает оплату, но после первой оплаты, возможность платить должна быть всегда.
Бывает ситуация, когда заказ возвращается в более ранний статус чем тот что разрешает оплату, но после первой оплаты, возможность платить должна быть всегда.
Таблица b_catalog_store_product судя по описанию дает возможность учитывать несколько количеств одного товара на складе.
Добавьте пожалуйста возможность добавления к ней пользовательских полей.
Добавьте пожалуйста возможность добавления к ней пользовательских полей.
Необходим аналог метода CIBlockParameters::AddPagerSettings() для компонентов, в которых основная выборка идет с помощью ORM. Сейчас чтобы добавить в настройки компонента параметры для новой "постранички" приходится писать свой вспомогательный метод.
Идея, которую хотелось бы тут изложить, не нова, но руки никак до нее не доходили.
Навеяна она сообщением на форуме:
В sql есть "каскадные операции" - удаление связанных записей или обновлние.
И хотя сейчас я слабо представляю каскадное обновление, но вот каскадное удаление или запрет на изменение/удаление уже отчетливо видно.
Прошу рассмотреть возможность реализации данной функциональности.
Навеяна она сообщением на форуме:
В sql есть "каскадные операции" - удаление связанных записей или обновлние.
И хотя сейчас я слабо представляю каскадное обновление, но вот каскадное удаление или запрет на изменение/удаление уже отчетливо видно.
Прошу рассмотреть возможность реализации данной функциональности.
Для коробочной версии Битрикс24 жизненно необходимо иметь возможность изменять стандартные js (например в всплывающие карточки звонка добавить новое поле или вывести доп.информацию), однако все "зашивается" на папку /bitrix/js/, а так как не предусмотрен штатный механизм для расширения js, то может стоит добавить папку /local/js/ для приоритетного замещения /bitrix/js/
Например при подключении core.js (/bitrix/js/main/core/core.js) проверялось бы наличие файла /local/js/main/core/core.js и в случае его существования подключался именно он.
Может для редакции БУС это не так актуально как для КП, но в КП это просто необходимость для кастомизации crm (да и например BX.ShowWait() можно кастомизировать)
Например при подключении core.js (/bitrix/js/main/core/core.js) проверялось бы наличие файла /local/js/main/core/core.js и в случае его существования подключался именно он.
Может для редакции БУС это не так актуально как для КП, но в КП это просто необходимость для кастомизации crm (да и например BX.ShowWait() можно кастомизировать)
В версии инфоблоков 16.5.4 вышла прекрасная функциональность для работы с разделами на новом ядре D7.
Правда документации пока нет (но ничего страшного) и можно было бы существенно увеличить возможности новой реализации:
1) Метод compileEntityByIblock мог бы возвращать не полное название класса, а объект этого класса. При этом его работа была бы эффективнее. Сравните 2 подхода:
Против
Мне кажется решение под номером 2 выглядит практичнее.
2) Предлагаю расширить модель SectionTable (или ее производные типа Section1Table) на runtime параметр: ELEMENT_COUNT - который бы доставал активные элементы, привязанные к соответствующему разделу.
Кейс: нужно отобразить только те разделы, где есть активные элементы.
Решение предлагаемое из коробки - составление своего runtime-поля для каждого getList/getRow (где оно требуется).
Если добавить штатное решение как SELECT поле и просто передавать его в массиве полей или соответственно по условию, то код будет выглядеть элегантнее и проще, а другие подобные поля, можно будет посмотреть и сделать по аналогии.
Правда документации пока нет (но ничего страшного) и можно было бы существенно увеличить возможности новой реализации:
1) Метод compileEntityByIblock мог бы возвращать не полное название класса, а объект этого класса. При этом его работа была бы эффективнее. Сравните 2 подхода:
use \Bitrix\Main\Loader;
use \Bitrix\Iblock\Model\Section as SectionFactory;
Loader::IncludeModule('iblock');
$sSection = SectionFactory::compileEntityByIblock(1);
$oEntity = new $sSection;
var_dump($oEntity->getMap()); |
Против
use \Bitrix\Main\Loader;
use \Bitrix\Iblock\Model\Section as SectionFactory;
Loader::IncludeModule('iblock');
$oEntity = SectionFactory::compileEntityByIblock(1);
var_dump($oEntity->getMap()); |
Мне кажется решение под номером 2 выглядит практичнее.
2) Предлагаю расширить модель SectionTable (или ее производные типа Section1Table) на runtime параметр: ELEMENT_COUNT - который бы доставал активные элементы, привязанные к соответствующему разделу.
Кейс: нужно отобразить только те разделы, где есть активные элементы.
Решение предлагаемое из коробки - составление своего runtime-поля для каждого getList/getRow (где оно требуется).
Если добавить штатное решение как SELECT поле и просто передавать его в массиве полей или соответственно по условию, то код будет выглядеть элегантнее и проще, а другие подобные поля, можно будет посмотреть и сделать по аналогии.
Добрый день.
Возник момент с кастомным кешированием в своем компоненте.
Согласно этому курсу (), подключение шаблона можно размещать как в кешируемой области, так и вне её.
При подключении шаблона в кешируемой области собственного компонента со сложным кешированием шаблон не отрабатывает вообще - сразу выводится html-кеш.
Разница в том, что в стандартных компонентах используется метод StartResultCache и при этом template.php кешируется полностью и выводится как html-кеш. При этом из кеша на хите достаются переменные VARS из файла кеша и передаются в component_epilog.php, что не происходит, если строить свое кеширование согласно вышеуказанному курсу.
Покопавшись в исходниках, выяснил, что в метод startResultCache() вшит также метод includeComponentEpilog(), которого нет в классах кастомного кеширования и в документации.
При этом входящие данные для него от родительского компонента в своем дочернем компоненте получить нельзя, так как свойство, в котором хранится путь и данные для метода includeComponentEpilog() лежат в родительском свойстве __component_epilog, которое имеет модификатор доступа private и недоступен в потомке.
В связи с этим кастомное кеширование получается неполноценным, т.к. для использования в шаблонах component_epilog, нужно подключение шаблона обязательно выводить из кешируемой области.
Прошу дать возможность разработчику самостоятельно подключать эпилог компонента в своем компоненте.
Возник момент с кастомным кешированием в своем компоненте.
Согласно этому курсу (), подключение шаблона можно размещать как в кешируемой области, так и вне её.
При подключении шаблона в кешируемой области собственного компонента со сложным кешированием шаблон не отрабатывает вообще - сразу выводится html-кеш.
Разница в том, что в стандартных компонентах используется метод StartResultCache и при этом template.php кешируется полностью и выводится как html-кеш. При этом из кеша на хите достаются переменные VARS из файла кеша и передаются в component_epilog.php, что не происходит, если строить свое кеширование согласно вышеуказанному курсу.
Покопавшись в исходниках, выяснил, что в метод startResultCache() вшит также метод includeComponentEpilog(), которого нет в классах кастомного кеширования и в документации.
При этом входящие данные для него от родительского компонента в своем дочернем компоненте получить нельзя, так как свойство, в котором хранится путь и данные для метода includeComponentEpilog() лежат в родительском свойстве __component_epilog, которое имеет модификатор доступа private и недоступен в потомке.
В связи с этим кастомное кеширование получается неполноценным, т.к. для использования в шаблонах component_epilog, нужно подключение шаблона обязательно выводить из кешируемой области.
Прошу дать возможность разработчику самостоятельно подключать эпилог компонента в своем компоненте.
Есть несколько предложений по d7. Возможно такие предложения уже звучали или даже уже в процессе внедрения, но мне не удалось их найти.
1. Добавить метод update с поддержкой фильтра. Пример:
2. Добавить метод delete с поддержкой фильтра.
3. Добавить метод batchInsert. Позволит добавлять одним запросом несколько записей. Пример:
1. Добавить метод update с поддержкой фильтра. Пример:
$connection->update($tableName, $data, $filter); |
3. Добавить метод batchInsert. Позволит добавлять одним запросом несколько записей. Пример:
$connection->batchInsert( 'book', ['NAME', 'DESC'], [ ["Запись 1", "Текст"], ["Запись 2", "Еще текст"], ] ); |
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
