Как правильно пользоваться created_at и updated_at (дата создания и обновления поста)?
Собственно все, вроде бы, как обычно: создаем пост - ставим текущую дату в оба поля, обновляем пост - ставим текущую дату в поле updated_at.
А теперь вопрос, по какому полю сортировать посты?
В чем сложность? А сложность вот в чем:
Создаю сегодня пост, но он большой и писать его приходится допустим 2-3 дня, по этому он висит в черновиках. Прошло 2-3 дня, а пост так и не опубликован, ну не дошли руки до него, за то были написаны другие посты за это время. В итоге получаем - если выведем посты по дате создания, то первый пост выйдет в конце, как давно созданный, хотя должен быть последним, выведем по дате обновления будет все как надо казалось бы, НО - нашлась опечатка в одном посте, в другом, поправил по 1 букве там и там и все, посты пересортировались как попало, неправильно получается.
Есть идеи как быть? Кто как выходит из этой ситуации?
Ну и за одно - какую дату выводить в посте? В метатег разумеется пойдет дата последнего изменения, а вот в самом посте дату создания/изменения?
Пока в голову приходит только создания еще 1 поля типа published для хранения даты, но это ж как то не правильно получается
created_at и updated_at использую как логгер создания и обновления публикации, а вот сам статус того, что статья опубликована можно изменять либо через статус записи, либо поле published, которое по умолчанию null, но если мы передаем из формы флаг того, что данная статья опубликована, то делаем $model->touch('published'); В TimestampBehavior есть метод пушаший дату в нужное свойство класса.
created_at и updated_at не влияют на статус публикации, они просто информационные поля. Сортировка сделана именно по полю published_at в которое ставится метка времени публикации записи. У меня там еще вагон и меленькая тележка различных условий, типа отложенная запись, прилепленная запись, прилепленная запись на первую\вторую\n-ю позицию, но сортировка происходит по полю published_at.
Обновляю его я принудительно, т.е. $model->touch('published_at');
Mylistryx: ну вот подозреваю автору надо сделать отложенную запись. Т.е. это еще дополнительное поле для времени активации? Или как вообще? Тоже тиресна.
Если отложенная публикация - то ручками в форме в это поле ($paublished_at) через DateTimePicker вставляем какое либо значение и в выборке тянем все, что меньше текущего time();
Андрей Токмаков: $model->touch('lastVisit') обновит значение и сохранит данные не вызывая валидацию и триггеры на событие, поэтому привык использовать его.
published_at - у меня в форме есть чекбокс "Опубликовать" и поле с датапикером и если стоит чекбокс и заполнено это поле, то в published_at записывается значение из этого поля. Если публикация не отложенная, то подставляется текущее значение time() и при этом меняется статус публикации.
Если же после снять чекбокс, то изменится только статус, соответственно если его обратно поставить - тоже, т.е. метка времени публикации не изменяется, хотя тут вы можете делать уже свою логику, и, например, обновлять время публикации после ее повторной отправки из корректуры.
Пример:
Создается новость (Н1) и ставится отложенная публикация на завтра на утро, на 9.00. Мы ставим чекбокс и выставляем дату и время отложенной публикации. В поле published_at запишется метка времени завтра, 9:00. Таким образом в выборку она начнет попадать только с завтрашнего утра, и если сейчас добавить еще одну новость (Н2) и не заполнять поле отложенной публикации, то порядок вывода у них завтра с утра после 9:00 будет:
1. Н1
2. Н2
3.. остальные новости в порядке убывания даты published_at
AlikDex: У меня так и происходит, по крону обновляется статус у публикаций (новостей, статей и прочего). Что то прилепляется, что от отлепляется, что то выводится, что то скрывается, т.е. я выбираю основную массу WHERE `status` = static::STATUS_PUBLISHED ORDER BY 'published_at' DESC. При этом еще кеш теггированый с зависимостями на обновление записей, но переписывать сюда все это нет смысла, т.к. достаточно много специфичной бизнес-логики.
Здесь я думаю достаточно будет кешировать результаты выборки и ставить зависимость на события добавления\обновления\удаления записей.
Тут надо задать себе вопрос "а зачем мне нужны эти даты?". Если просто что б было, так может проще сортировать по id?
Если у Вас посты пишет по три для только администратор, так обновляйте в контролере админки created_at или выведите админу возможность менять эту дату в виде datetime picker. Тогда он еще и отложенные публикации сможет делать.
Тут даже если исходить из банальной логики created_at - это дата публикации и не дата внесения в базу данных.
Можно проставлять дату created_at, только при наличии галочки опубликовать, например.
По ид не подойдет все по той же причине, когда будет в черновиках запись с ид 1 могут появиться записи 2 и 3 и в итоге запись с ид 1 будет выведена последней, а не первой.
А вот на счет created_at я уже тоже подумал, что бы ставить ее только тогда, когда статус будет выставлен "опубликовано" и держать например null пока статус "черновик".
Андрей Токмаков: Ну да. Вообще удобно иметь статус отдельно. И просто при смене статуса с черновик, на опубликовано ставить дату публикации. Это даст возможность выключать статьи. Хотя можно и затирать им дату публикации. Но наличии отдельного поля дает больше места для маневра (на модерации, отклонена, устарела. переделать, актуализировать, опубликовано и т.д.)
Сложный
Средний
