ВГ
Так и думал сделать (даже проще: создать io.Writer и из него строки перекидывать в Sentry). Но как-то странно накручивать костыльные обёртки при наличии официальной библиотеки.
странно, но мне кажется, в основном люди логрус/зеролог юзают
Size: a a a
2020 May 08
ВС
странно, но мне кажется, в основном люди логрус/зеролог юзают
попробовал тут zap на одном проекте, мне чисто по удобству api понравился даже больше, но вот логировать с context в него не получится (как можно в logrus), поэтому breadcrumbs не будет
DP
Так и думал сделать (даже проще: создать io.Writer и из него строки перекидывать в Sentry). Но как-то странно накручивать костыльные обёртки при наличии официальной библиотеки.
официальный логгер - это позор джунглей же
олни там думают, что логам не нужны уровни
олни там думают, что логам не нужны уровни
DP
попробовал тут zap на одном проекте, мне чисто по удобству api понравился даже больше, но вот логировать с context в него не получится (как можно в logrus), поэтому breadcrumbs не будет
что именно не получится?
ВС
ну сходу не нашел как пробрость в него context.Context (в logrus было entry.WithContext(ctx) - потом он был доступен в хуках)
AE
странно, но мне кажется, в основном люди логрус/зеролог юзают
Ну, я для старта проекта смысла не вижу подключать лишние зависимости. И нативный логгер сделан довольно универсально: по-идее, все остальные должны бы под него интерфейсы выдавать. Чтобы и единообразно, и совместимо, и переезжать проще.
Но вот хрен там...
Но вот хрен там...
ВС
да вот не универсально от слова совсем, и не интерфейсами
ВС
так нужна обертка, в lib/pq это функция pq.Array
либо тип, который реализует sql.Scanner (для массивов такие обертки точно были)
либо тип, который реализует sql.Scanner (для массивов такие обертки точно были)
ВС
через AssignTo
ВС
туда можно передать *[]string и в него будут сложены элементы
ВС
тогда через Set([]string)