DK
вопрос в том где надо группировать чтобы клиенту показать :)
Естественно в базе, иначе создание всех инстансов сожрёт памяти больше, чем могло бы сожрать
Size: a a a
2020 September 21
f
не, только экстендить, и помоему 2 разные версии постреса на 1 инстансе не поднимешь
не понимаю что значит экстендить, они же в сам хомстед по умолчанию поставлены, целых 4 штуки разных
SP
? религия не позволяет?
запрос не позволит, синтаксис
DK
Обратные кавычки?
такиеSP
Естественно в базе, иначе создание всех инстансов сожрёт памяти больше, чем могло бы сожрать
+
DK
Или альяс другой
SP
так не важно, event_date это колонка в бд timestamp
S
Естественно в базе, иначе создание всех инстансов сожрёт памяти больше, чем могло бы сожрать
не, ну это то само собой, хотя есть lazy collections :)))
я о другом
если группировка в базе дает выборку нужных событий - то проблем нет
и не понятно мне почему выборка из базы может быть не верной
я о другом
если группировка в базе дает выборку нужных событий - то проблем нет
и не понятно мне почему выборка из базы может быть не верной
DK
не, ну это то само собой, хотя есть lazy collections :)))
я о другом
если группировка в базе дает выборку нужных событий - то проблем нет
и не понятно мне почему выборка из базы может быть не верной
я о другом
если группировка в базе дает выборку нужных событий - то проблем нет
и не понятно мне почему выборка из базы может быть не верной
Из-за смещений временных зон
SP
SP
и решение - это установка таймзоны юзера в запросе
DK
2000-01-01 22:00:00 в одной временной зоне - это 1 января, а в другой 31 декабря
DK
Т.е. там 31 декабря
A
Переслано от AlexOneTrek
Никто не знает, как при выводе trix текста, убрать ту нижнюю информацию, и что бы фотка выводилась без ссылки
S
тут надо вникнуть, @papalapa по-моему понял проблему основную )
ты можешь просто в клиенте mysql написать запрос без group by и посмотреть возвращает он тебе нужные события или нет,
далее, как будут выбираться нужные - добавляешь group by и смотришь что не так
добавляешь чего не хватает
дальше опять конвертируешь даты на клиенте перед отображением
в данном случае нет смысла заморачиваться с TZ в базе
далее, как будут выбираться нужные - добавляешь group by и смотришь что не так
добавляешь чего не хватает
дальше опять конвертируешь даты на клиенте перед отображением
в данном случае нет смысла заморачиваться с TZ в базе
DK
😀 так после чистого запроса и group by уже неверная (с точки зрения таймзоны пользователя) выборка
DK
А тащить это всё в php для группировки - лишние накладные расходы
SP
😀 так после чистого запроса и group by уже неверная (с точки зрения таймзоны пользователя) выборка
+
SP
А тащить это всё в php для группировки - лишние накладные расходы
+
S
2000-01-01 22:00:00 в одной временной зоне - это 1 января, а в другой 31 декабря
да
в базе эти события хранятся в UTC
поэтому приводим дату к UTC, получаем события, переводим их дату к пользовательской
елси нужно посчитать количество событий - оно посчитается правильно, т.к. мы же выборку делаем по диапазону UTC который соответствует дате запрошенной пользователем
в базе эти события хранятся в UTC
поэтому приводим дату к UTC, получаем события, переводим их дату к пользовательской
елси нужно посчитать количество событий - оно посчитается правильно, т.к. мы же выборку делаем по диапазону UTC который соответствует дате запрошенной пользователем