Надо в трекер добавить себе TODO.
Полез гайд коханы почитаю…
Надо в трекер добавить себе TODO.
Полез гайд коханы почитаю…
А как тогда AR будет работать? На основе чего?
samdark
Что значит на основе чего?
Ведь что такое AR? Это доступ к бд через ООП.
Допустим есть запрос:
INSERT INTO `table` (p1, p2) VALUES ('value', 123);
Собственно данный паттерн должен нам позволить сделать так:
class Table extends ORM
{
protected $p1;
protected $p2;
//Далее указание название таблицы
}
$table = new Table();
$table->p1 = 'value';
$table->p2 = 123;
$table->save();
Зачем вот здесь получать информацию о таблице? Да конечно сделав это мы можем выполнять предварительную проверку существования полей, при этом не писав protected $p1;…, но стоит ли это?
Lion__
Т.е. отношения тянуть из метаданных стоит, а поля нет? Я вспомнил, почему Yii отношения генерит через Gii, а не строит динамически на основе схемы. Не во всех случаях можно однозначно сказать, что имел ввиду тот, кто строил базу. То же many to many отлично заменяется на два has_many и два has_one и иногда как раз нужен второй вариант. Да, в Ko3 также можно переопределить отношение, но пока в этом случае поймёшь, почему оно работает не так, как ты хочешь — вырвешь себе все волосы. Магия, если она есть, должна обязательно быть однозначной и, по возможности, простой.
Не совсем. AR — это не просто доступ к БД через ООП (тот же PDO — это тоже ООП), это отображение БД на объект.
Стоит. Становится можно использовать свои поля. Например, завести какой-нибудь флажок и не бояться, что он попытается писаться в базу и вызовет ошибку. Плюс в Yii схема не только для этого. Например, учитываются значения, проставленные полям по умолчанию.
Нее, то я показал разницу, а сейчас своё мнение.
В плане несуществующих полей?
А это зачем? Не вижу смысла в этом вообще…
Значения по умолчанию — штука довольно удобная, но, в общем-то, опциональная: не выставишь — ничего вытягиваться не будет. Просто приятная плюшка.
Главный плюс реализации AR как в Yii или Rails в том, что не надо по два раза объявлять поля: и в базе и в коде. Соответственно время разработки сокращается, рутина уменьшается, разработчик устаёт меньше. А кеширование схемы сглаживает падение производительности.
Ну да.
Значения по умолчанию — штука довольно удобная, но, в общем-то, опциональная: не выставишь — ничего вытягиваться не будет. Просто приятная плюшка.
Не вижу её ‘удобность’… Разве что:
$post = new Model_Post;
$a = $post->p1;
где p1 это поле которое имеет значение по умолчанию. Больше применения я не вижу. Да и если использовать тот вариант который я показал для примера, то:
protected $p1 = 'value';
Таким образом нам не надо лезть в бд что бы изменить значение по умолчанию
не выставишь — ничего вытягиваться не будет.
В таком же варианте мы тоже получим информацию о полях, а зачем?)
Представьте вот я в Post сменил название поля p1 на p3, что мы получим? Ошибку что p1 не найдено, нам надо будет смотреть логи где был вызов данного свойства, и изменять на p3.
Так же само можно получить ответ от бд, в которой будет написано что такое то поле не существует.
Если мы начали искать пост, значит зачем-то он нам нужен. Или я чего-то не понимаю?
И чем это отличается от изменения явно прописанного свойства? Тем, что меняет в большем количестве мест?
Да и смотреть логи в последних версиях Yii достаточно приятно. Он и файлик покажет с исходником и строчку выделит.
Схема БД врать не может. Если она врёт — базе конец.
Если мы начали искать пост, значит зачем-то он нам нужен. Или я чего-то не понимаю?
Я имел введу зачем здесь структура полей
И чем это отличается от изменения явно прописанного свойства? Тем, что меняет в большем количестве мест?
До сохранения можно прописать просто self::$p3 = $self::$p1, такой способ более логичен будет именно в явно прописанном свойстве
Схема БД врать не может. Если она врёт — базе конец.
Вы меня не поняли… А я устал доказывать, всё равно вы будете стоять на своём…