RS
приемлимо ли возвращать unix timestamp в качестве JSON number вместо текстового RFC3339? 🤔
Size: a a a
2020 February 24
а
приемлимо ли возвращать unix timestamp в качестве JSON number вместо текстового RFC3339? 🤔
вполне
RS
мне кажется таймстамп даже лучше
поч?
очевидный минус: non human-readable
плюс: чуток оптимальнее по производительности
очевидный минус: non human-readable
плюс: чуток оптимальнее по производительности
KR
приемлимо ли возвращать unix timestamp в качестве JSON number вместо текстового RFC3339? 🤔
Если принимающая сторона умеет в числа больше u32, а то могут быть проблемы в 2027м
а
поч?
очевидный минус: non human-readable
плюс: чуток оптимальнее по производительности
очевидный минус: non human-readable
плюс: чуток оптимальнее по производительности
потому что с числами работать проще, нежели со строкой
ВС
приемлимо ли возвращать unix timestamp в качестве JSON number вместо текстового RFC3339? 🤔
Оно конечно работать будет, но без таймзоны можно словить кучу багов
YG
Не понимаю как. Обьясните подробнее, пожалуйста. Вот, к примеру: есть запрос к БД, он выполняется 300мс, а у Вас квота выделена 200мс. Они капнули, Вам нужно отменить выполняющийся запрос в БД и вернуть юзеру 408 ошибку. Как Вы делаете отмену мьютексом?
не, отмену я конечно не делаю мьютексом.
У меня с запросами своя история - нет больших запросов которые бы выполнялись по большому количеству времени, так что тут Ваш пример я не раскрою.
У меня специфика немного другая - realtime communications и для этого дела - у меня нет вариантов формировать большие запросы.
чтобы обработать лимит времени выполнения так просто не нахожу решения пока без контекста
У меня с запросами своя история - нет больших запросов которые бы выполнялись по большому количеству времени, так что тут Ваш пример я не раскрою.
У меня специфика немного другая - realtime communications и для этого дела - у меня нет вариантов формировать большие запросы.
чтобы обработать лимит времени выполнения так просто не нахожу решения пока без контекста
а
поч?
очевидный минус: non human-readable
плюс: чуток оптимальнее по производительности
очевидный минус: non human-readable
плюс: чуток оптимальнее по производительности
human-readable можно сделать на клиенте какой угодно
KR
Оно конечно работать будет, но без таймзоны можно словить кучу багов
Ну если считать что сервер всегда отдаёт UTC, то проблем не будет
RS
Если принимающая сторона умеет в числа больше u32, а то могут быть проблемы в 2027м
технически JSON number это IEEE 754 у которого макс. 53 бита челочисленной части AFAIK
а
Оно конечно работать будет, но без таймзоны можно словить кучу багов
обычно utc же
ВС
В таком случае надо следить за этим и при генерации json-а не забывать дёргать UTC()
RS
Бывает приходит от юзверя в других таймзонах и так и пишется в БД. Соответственно и назад вместе с его таймзоной выплёвывается. Когда всё на RFC3339, то для кода это абсолютно прозрачно и проблем нет.
в данном случае с клиента ничего не приходит
KR
не, отмену я конечно не делаю мьютексом.
У меня с запросами своя история - нет больших запросов которые бы выполнялись по большому количеству времени, так что тут Ваш пример я не раскрою.
У меня специфика немного другая - realtime communications и для этого дела - у меня нет вариантов формировать большие запросы.
чтобы обработать лимит времени выполнения так просто не нахожу решения пока без контекста
У меня с запросами своя история - нет больших запросов которые бы выполнялись по большому количеству времени, так что тут Ваш пример я не раскрою.
У меня специфика немного другая - realtime communications и для этого дела - у меня нет вариантов формировать большие запросы.
чтобы обработать лимит времени выполнения так просто не нахожу решения пока без контекста
О том и речь. В пакете database/sql в std методы-братья с WithContext именованием в своё время появились не просто так, от балды.
YG
О том и речь. В пакете database/sql в std методы-братья с WithContext именованием в своё время появились не просто так, от балды.
да я как бы и не спорю, но в общем и целом, поставив ограниение на время выполнения запроса можно же отловить ошибку выполнения запроса ограниценную таймаутом и выйти из функции которая будет вызвана отдельной goroutine