Для работы со штатным ORM нужно заводить модель для каждой таблицы. Всегда. Она может быть вообще пустой, но она должна быть. Ну, необязательно совсем пустой, там могут быть описания связей и всё такое.

Но всё выше сказанное не означает, что больше в моделях писать нечего. Ниже я попытаюсь систематизировать, что ещё такого можно, и даже стоит написать именно в модели.

1. Перечень полей
=========================
В модели обязательно должны быть описаны все поля таблицы. Подробнее проблема описана тут

Читать далее »

Я долго не мог понять, чего мне не хватает в штатном ORM от Kohana. А не хватало именно возможности использования выражений.

Бывало напишешь по-наивности какое-нибудь выражение прямо в where. Например, так:

1

where('concat(first_name," ",last_name)',"like","%$searchstring%")...

А потом получаешь ошибку, что нет такого поля 'concat(first_name," ",last_name)'

И вот однажды я в недрах интернетов нашёл решение, которое конечно же решил положить в мою копилку шпаргалок. Всё дело в использовании функции DB::expr. Вот например так:

1
2
3
4
5
6
7

$searchresult=ORM::factory("user")->
  where(   DB::expr('concat(first_name," ",last_name)'),
                           "like","%$searchstring%")->
  order_by("id","desc")->
  limit($data['per_page'])->
  offset($data['offset'])->
  find_all();

Воистину, ORM может всё, только нужно знать все его трещинки.

Штатный ORM у Kohana практически на каждое шевеление создаёт запрос “SHOW CREATE TABLE blablabla“.

Я как-то не придавал этому значения раньше, но похоже этот запрос довольно ёмкий по времени, у меня он почему-то занимает до пол-секунды в плохую погоду (погода зависит от текущей загрузки хостинга). А если страница пестрит обращениями к БД, которые делаются через ORM, то ждите того, что треть запросов будет именно “SHOW CREATE TABLE“.

Как бы сделать так, чтобы ORM так не делал? Ведь структура таблиц работающего сайта практически не меняется годами!

Решение простое! Нужно немного переопределить метод list_columns класса ORM так, чтобы он кешировал структуру таблицы и дважды не бегать.

Читать далее »

Модуль Image это просто суперский модуль! С его помощью программист на Kohana может легко и не сильно вдаваясь в детали обрабатывать изображения. Можно конечно залезть в библиотеку GD и делать всё там вручную. Но так пусть делают у кого времени вагон. А нам нужен результат, и быстро.

У модуля один только недостаток. Нет описания. То есть его просто нет (на момент написания материала мануал по модулю был пуст). И я спешу хоть немного восполнить пробел

Хоть всё можно подсмотреть в коде, тем не менее попробую дать небольшое описание этому модулю. Без претензий на полноту, только в качестве начального толчка.

Читать далее »

C базами данных в Kohana принято работать через ORM. Но не секрет, что ORM не покрывает всех нужд и потребностей. В таких случаях нужно что-то другое.

Для самых нетерпеливых – прямые запросы к БД. Метод простой и эффективный. Только ваши запросы и ничего больше. Минусы этого метода в том, что составляя запрос вы сами несёте ответственность за возможную инъекцию. Работать можно, но нужно тщательно проверять все поступающие данные.

Query Builder
===================
Это нечто среднее между вышеописаными методами. О нём я и хочу поговорить в этом посте.

Читать далее »