Правки для старой версии битрикса + тегированный кеш для элементов - #26
Правки для старой версии битрикса + тегированный кеш для элементов#26MsNatali wants to merge 12 commits into
Conversation
| $value = isset($buckets[$key]) ? $buckets[$key] : ($multiple ? [] : null); | ||
| } | ||
| $primaryModel->populateRelation($relationName, is_array($value) ? (new Collection($value))->keyBy(function ($item) {return $item->id;}) : $value); |
There was a problem hiding this comment.
function ($item) {return $item->id;} можно заменить на 'id'
| $callback = function() use ($sort, $filter, $groupBy, $navigation, $select, $chunkQuery) { | ||
| if (static::isManagedCacheOn()) { | ||
| ServiceProvider::cacheManagerProvider()->StartTagCache(static::$cacheDir); |
There was a problem hiding this comment.
Назначение класса ServiceProvider - подключить пакет в приложение, этот класс не должен использоваться внутри пакета, в моделях и т д.
Так что стоит создать новый класс, назвав его, например BitrixWrapper и в нём методыgetCacheManager и setCacheManager
| return $className::$method(...$parameters); | ||
| } | ||
| public function getCount($filter) |
There was a problem hiding this comment.
Не хочу добавлять костыли для старых версий Битрикса.
Если кому-то это нужно - могут добавить это в базовую модель своего приложения
| return $config::GetOptionString('main', 'component_managed_cache_on', 'N') == 'Y'; | ||
| } | ||
| public function exec($query) |
There was a problem hiding this comment.
Тоже не хочу это мержить.
Через этот метод можно сделать какой угодно прямо запрос к базе.
Формат ответа меня тоже смущает, в моделях мы оперируем не только коллекциями, но и единичными объектами, числами (count) и т д.
У моделей и так слишком много ответственностей, это уже явный перебор.
Если нужно сделать суперэффективный прямой запрос к БД минуя то как модели (а по-сути Битрикс под ними) строит запрос можно ну взять и написать этот прямой запрос в БД вне моделей или сделать в конкретной модели FooModel метод getBarCollection(), внутри которого делать уже всё что душе угодно.
Написал комментариев.
|
| * @param string|array $methodAndParams | ||
| * @return $this | ||
| */ | ||
| public function fetchUsing($methodAndParams) |
There was a problem hiding this comment.
С GetNextElement самое важное как он будет вести себя с разными свойствами (особенно множественными).
У нас есть два типа инфоблоков (1 и 2). В идеале чтобы GetNextElement с обоими работал или если для какого-то одного, то зафиксировать это потом в документации.
Зачем 'PROPERTY_*' в select если свойства потом получаются новыми запросами через GetProperties?
Что будет если разработчик хочет получить только часть данных через Product::query()->select('ID', 'NAME', 'PROPERTY_FOO')'? Можно ли отдавать ему при этом только их а не все свойства и поля?
No description provided.