Ага, смешно. Это то понятно. Но их вообще не должно быть в ответе - поскольку "я же их не выбираю.."zelenin писал(а):вы же не выбираете эти поля в запросе, вот они и нулевые - ->select('n,fn')
В коротком случае объявления всё именно так и происходит.
--
Забавно, то точно такие же ответы приходят при пустом селекте ( return $this->hasOne(Pamjatnik::ClassName(), ['id' => 'id_pamjatnik'])->select(''); )
// И при длинной и при короткой форме объявления "fields()"
При короткой форме сервер возвращает поля 'name', 'n' и 'fn' , при длинной соответственно все поля, причём 'name', 'n' и 'fn' заполненные, а остальные == 'null'.
Понятно, что поля 'n' и 'fn' всегда извлекаются (для вычисления 'name'), но непонятно зачем это происходит при пустом селекте...
---
UPD
Был слегка неправ (в выделенных местах), каюсь. // не в той модели запросил пустой селект..
Поведение слегка проясняется. При пустом селекте возвращаются все поля объекта (заполненные). И это плохо - например для программного формирования содержимого селекта. По моей наивной логике, пустой селект должон возвращать пустой ответ. Разве нет?
Eсли селект не пуст - интереснее.
При выборе любых полей кроме n и fn, в поле name возвращается null. Если выбирается n или fn (но не оба) - вычислимое поле вычисляется как если бы незапрошенное поле было равно null. Если оба - вычисляется правильно.
В принципе поведение логичное, но на мой вкус неправильное... Мне зачем на клиенте лишние данные? Я бы хотел получить только поле name без довесков в виде fn и n. К тому же этот пример вычислимого поля весьма примитивен, есть (по замыслу) более сложные (требующие больше входных данных). И какой смысл отправлять их все клиенту? Идея была - экономить траффик и память на клиенте (таблиц у меня уже сейчас 33 штуки, а буде больше - около семидесяти)....