Вы просто не до конца представляете себе как работает кеширование в onPHP. Там никто за вас ничего не делает. Начнем с того, что по дефолту все вообще работает без кэша. Далее, если есть потребность, вы можете выбрать одну из нескольких стратегий кэширования и выбрать куда кэшировать — файлы, мемкэш…
Кроме того, вы в состоянии не только определять стратегию кэширпования для конкретного DAO (класса объектов), но и для конкретного запроса.
Например:
$query = OSQL::select()->...;
Book::dao()->getByQuery($query, Cache::DO_NOT_CACHE); Собственно второй параметр может быть временем кеширования в секундах.
Чтобы не жралась оперативка, там где это действительно нужно, можно кешировать список id-шников например, а потом по id так же доставать объекты из кеша.
Нет, там нету тормозов. Там все кешируется при желании и кладтся в один файлик. В файлике асоциативный массив в котором ключик это имя класса, а значение — путь к файлу. Так что все работает довольно быстро.
Пробовал кстати запускать без кэширования путей и тогда да, сильно тупит. Примерно 0,3 сек на моем буке добавляется толькоза счет поиска и инклюда всех необходимых файлов.
1) Если пишете личный блог то да, бессмысленно, а если работаете над крупным проектом, то будет нехорошо, если он после запуска ляжет.
2-3) Если кэш продержится (прежде чем устареет) хотя бы 5 минут, когда страничку посетит сотня, другая человек, то получается что есть резон кэшировать. К тому же, в реальной жизни редко возникает необходимость показывать стопроцентно актуальную информацию и лезть за ней в базу при каждом рефреше.
4) А вы попробуйте)
Стоит еще добавить, что на поля формы, при необходимости, можно вешать множество ограничений и фильтров, что избавляет от типовых проверок, которые иначе пришлось бы писать вручную.
Нет там никакой такой опции. Можно только запустить генерацию без валидации БД.
По поводу того, что не обновляет базу автоматом — у меня есть некие предположения.
1) Никто не запускает генерацию меты на продакшене.
2) В MySQL вместо boolean используется тип tinyint. Так вот когда запускаешь генерацию меты, в которой объекты содержат булевые поля, скрипт предлагает накатить альтеры для смены типа с tinyint на bool. Это видимо недоработка в самом фреймворке, потому, что он явно развивается с прицелом на Postgres в ккачестве основной базы. MySQL там идет «что бы было». Получается, если бы база автоматически апдейтилась, то скрипт дергал бы её каждый раз по таким пустякам.
Хотя определенно есть смысл в том, что бы ввести новый флаг для генерации таблиц. Собсна это фопрос к Sherman-у )))
Кол-во энергии всегда причем. Что-то не может взяться из ничего. Мост жесткая конструкция, которая должна гасить колебания. По поводу ветра — нам с вами никогда не понять какие потоки там действуют, не побывав на «месте преступления».
Согласен, но этот идеальный случай отличается от случая с мостом нулевыми потерями энергии. Для резонанса надо чтобы в систему входило больше энергии чем поглощалось.
Ну… как бы мост имеет жесткость и должен гасить колебания. Значит энергия как минимум должна быть больше той, что гасится самой конструкцией. Я думаю это довольно много для моста на опорах.
Если ваше мнение на тот момент изменится, рекомендую почитать про сыроедение.
Поэтому лучше будет если каждый будет переживать за свое здоровье, тогда и нация будет здорова.
Кроме того, вы в состоянии не только определять стратегию кэширпования для конкретного DAO (класса объектов), но и для конкретного запроса.
Например:
$query = OSQL::select()->...;
Book::dao()->getByQuery($query, Cache::DO_NOT_CACHE); Собственно второй параметр может быть временем кеширования в секундах.
Чтобы не жралась оперативка, там где это действительно нужно, можно кешировать список id-шников например, а потом по id так же доставать объекты из кеша.
Пробовал кстати запускать без кэширования путей и тогда да, сильно тупит. Примерно 0,3 сек на моем буке добавляется толькоза счет поиска и инклюда всех необходимых файлов.
2-3) Если кэш продержится (прежде чем устареет) хотя бы 5 минут, когда страничку посетит сотня, другая человек, то получается что есть резон кэшировать. К тому же, в реальной жизни редко возникает необходимость показывать стопроцентно актуальную информацию и лезть за ней в базу при каждом рефреше.
4) А вы попробуйте)
Form::create()->
add(
Primitive::string('pass')->
setImportFilter(Filter::textImport())->
setMin(6)->
isRequired()
)->
add(
Primitive::string('name')->
optional()
)->
add(
Primitive::string('description')->
setImportFilter(
Filter::chain()->
add(Filter::textImport())->
addFilter(Filter::stripTags())
)->
optional()
);
По поводу того, что не обновляет базу автоматом — у меня есть некие предположения.
1) Никто не запускает генерацию меты на продакшене.
2) В MySQL вместо boolean используется тип tinyint. Так вот когда запускаешь генерацию меты, в которой объекты содержат булевые поля, скрипт предлагает накатить альтеры для смены типа с tinyint на bool. Это видимо недоработка в самом фреймворке, потому, что он явно развивается с прицелом на Postgres в ккачестве основной базы. MySQL там идет «что бы было». Получается, если бы база автоматически апдейтилась, то скрипт дергал бы её каждый раз по таким пустякам.
Хотя определенно есть смысл в том, что бы ввести новый флаг для генерации таблиц. Собсна это фопрос к Sherman-у )))