
dwd
— при таких изменениях вам все равно придется вносить коррективы и в свои правки
— однако вам не придется ничего мержить и искать, вы сразу будете видеть какая вставка где отвалилась
$value = $prop['handler']->store($value, false); if (!$value) { continue; } // а тут наш $value содежит что? Ну конечно ту же самую охинею, которую мы обычно пишем в БД $filters[$name] = $value; // а куда потом вся эта охинея попадает? ну конечно же $page_uri и следом в ссылки фильтра, пагинацию
Если мои глаза меня не обманывают, то методу store не место в фильтре. Я читаю документацию, подготавливаю данные к записи в БД, у меня все хорошо. А потом они вот в таком подготовленном виде почему-то пытаются протиснуться в фильтр, хотя для фильтрации я не просил их трогать. Может я опять чего-то не понимаю, но мне кажется, что если метод придуман для подготовки перед записью в БД, то давайте там его и использовать. Если для фильтра нужен подобный метод, давайте его добавим. На данный момент мы переписываем все ранее написанные поля согласно новым правилам. Если раньше все было четко и понятно, то теперь мы должны добавлять проверку контекста и исходя из этого задавать себе вопрос "Должен ли метод, описанный в документации как метод, предназначенный для подготовки данных перед записью в БД выполнить эту самую подготовку"? Один я нахожу в таком положении вещей разрыв шаблона?
1. Из головы, если отвечать буквально.
2. Это значения не для создания фильтров, а из созданных фильтров, т.е. из формы фильтра. И они не должны быть обязательно идентичными. Более того, в некоторых полях они и не идентичные.
3. Не понял вопроса, но вы можете обрабатывать как угодно, исходя из контекста вызова.
4. Я пока не вижу, что необходимо исправить. Все штатные поля, и доступные мне нештатные, работают корректно.
Судя по вашим ответам вы ничего из того, что я написал не поняли. Давайте попробуем так
Пример 1(допустим мультисписок c индексами 1,2,3,4,5,6)
public function store($value, $is_submitted, $old_value=null){ } public function getFilterInput($value){ return parent::getInput($value); } public function applyFilter($model, $value) { // я в фильтре выбрал значения 3 и 5 // $core->request содержит array(3, 5) // а чему по- вашему здесь $value равен? // мне кажется, что тут должен быть массив значений, выбранных в списке // но с вашими нововведениями его здесь нет return $model->filterLike($this->name, "%{$value}%"); }
public function store($value, $is_submitted, $old_value=null){ $model = cmsCore::getModel('mycontroller'); $model->save($this->item['id'], $value); return 1; } public function getFilterInput($value){ $model = cmsCore::getModel('mycontroller'); $value = $model->load($this->item['id']);// //строим выпадающий список } public function applyFilter($model, $value) { // а чему по- вашему здесь $value равен? // мне кажется, что тут должен быть массив значений, выбранных в списке // но с вашими нововведениями его здесь нет }
Постараюсь изложить его как можно четче и очень надеюсь услышать ответ. Вопрос про вот этот небольшой фрагмент кода из фильтра в типах контента и виджета фильтра:
$value = $prop['handler']->store($value, false); if (!$value) { continue; } $filters[$name] = $value;
1. Откуда возникла такая идея и вообще мысль, что процесс создания фильтров в этом нуждается?
2. Почему значения, которые мы записываем в БД и значения, которые мы используем для создания фильтров должны обязательно быть идентичны?
3. Исходя из вопроса 2 — как быть, если например в БД поле пишет любое символическое значение(например любой символ или единицу), а данные хранит во внешней таблице? Как результат фильтре в поле мы выбрали что угодно, до самой фильтрации долетела единица. Есть масса таких случаев, но этот самый простой.
4. Это новые правила игры к которым надо привыкать или это будет переосмыслено и исправлено?
Заранее благодарен за ответ.
В смысле лежит? Из чего вам такой вывод навеяло? Вы не умеете читать легенду на графиках?Ваш пример на скрине на www.smartape.ru/ лежит?
На моем скриншоте среднее время обработки запроса составляет 0,05 секунды, на вашем 0,15 секунд
Частота безусловно важна, но есть еще один такой фактор как архитектура процессора. Взять тот же Ryzen — одним кликом мыши 4 физических ядра превращаются в 8 виртуальных ядер. И понятное дело, что ни одно из них не может тягаться с натуральным интеловским. Для ряда специфических задач это даже дает прирост производительности процессора в целом. Но этот же подход в отношении сервера делает его немощным, хотя согласно тарифу вам выделили именно столько ядер сколько вы и просили и с обещанной вам частотой.но все таки от того какое ядро и условно 2 ггрц в нем или 3,5
Зелененький, значит хороший))У меня вышло так по сайту, это хороший результат? )
Вы про мой результат? Да, это сайт на инстанте с длефолтным шаблоном и без каких-либо дополнительно добавленных виджетов, что равносильно свежеустановленной системе. В случае если у вас отличный от дефолтного шаблон, масса вимджетов и т.д. естественно ваш сайт будет медленее.Это тест инстанта с ноля?
Да вот перед тем как прошлый пост написать проверил на всякий случай. Замечательно себя ведет.А сейчас как ведет себя ваша BrainyCP?
Не буду вступать в дискуссию по этому поводу, но другой способ увеличения процессорной мощности до сих пор науке неизвестен. Наращивание происходит только количеством ядер, поскольку делать ядра с частотой в 100500ГГц человечество еще не научилось. Когда научится тогда мы сможем завести полемику на тему что лучше — 1 ядро на 30ГГц или 10 ядер по 3ГГц.Про количество ядер не согласен.
Проверьте время и дату на сервере.
Мы ж здесь вроде об инстанте беседуем, а не о разных сайтах. Нам разные не нужны))
Да я ж не против, я только за. Попробуйте повторить, проверим насколько быстры ваши nvme-диски))Я конечно уважаю DWD, но вынужден опять поставить "на вид"
loaddy.com