не понял

а, там же не значения сравниваются, а просто типы, так что претензия отпадает

а вот кстати вопрос - в Is вначале сравниваются типы и при их совпадении сразу возвращается true, не нужно ли сравнивать то, что и элементы совпадают?

в смысле сразу проверять что target ==we? да, можно, это будет эффективнее. Но там дальше это всё равно проверяется в Is

не, я видимо немного не так написал
в данной реализации один multiError с одним набором не будет отличим от multiError с другим набором

#string #json #[]json #psql
Добрый день!

Есть небольшой вопрос.
Есть []byte, которые я получаю из psql, такого вида (без \n):

{
  "{\"foo\":1,\"boo\":\"100\"}",
  "{\"foo\":2,\"boo\":\"100\"}",
  "{\"foo\":3,\"boo\":\"100\"}"
}

Это массив json-ов и мне нужно с этим как-то работать.
Только есть проблема, что вместо [, ] тут {, }.
Подскажите, пожалуйста, какой-нибудь простой способ смены этих скобок.

Пример в playground:
https://play.golang.com/p/a-fJlFHsAkq

так есть же специальный враппер pq.Array, который мапит массив postgres в массив гошный, работает в обе стороны

там если multiError содержит две ошибки одного типа (например оба os.Open вернули *os.PathError) то errors.As/Is позволит посмотреть только одну из них. Способы решения  -  либо добавить к типу multiError итератор, либо завести кастомный тип реализующий ошибку, для которого тонко настроить As/Is. Я вот пока не уверен как лучше

я скорее вот про такую доработку https://play.golang.org/p/6qPrqHI9zfW (см Is)

Возник у нас с коллегами на работе спор. Проблема в том, что мой оппонент утверждает, что сервис не может быть пакетом и это плохо. Я так и не понял, чем это плохо, кроме того, что я теперь не могу использовать go get. И вот это уже плохо и неудобно. При этом в качестве альтернативы предлагается монорепа, в которой хранятся все зависимости и протофайлы. Я же предлагаю всё хранить в локальной репе, рядом с сервисами и воспринимать любой сервис, любую репу как пакет.

Подход моего оппонента для меня выглядит неудобным, поскольку в монорепу будут пушить все и это может вызвать проблемы в виде конфликтов. Кроме того, я вижу также неудобство в версионировании. И третий момент, мне кажется это неудобным с точки зрения разделения логики. Таким образом мы получаем монолитную репу. А микросервисный подход здесь оказывается в стороне (именно его мы пытаемся использовать у нас в проекте).

Таким образом, я бы хотел услышать за и против одной стороны и другой.

(микро)сервисы ортогональны устройству репы

да, это логично

но почему сервис не может быть пакетом?

Что логично? Что из двух вариантов?

Поясните

Я тоже не очень знаю

А если я просто стащу оттуда Сканер - это не гуд?)
https://play.golang.com/p/KrkRi3HQvrs

ваше право конечно, но... зачем?

Вам, как уже выше сказали, лучше использовать pq.Array.
Либо изменить запрос на базе таким образом, чтоб он не массив возвращал, а json-массив.

А зачем вам вообще делать микросервис пакетом? Чтобы делать go get и юзать внутренние конструкции другого микросервиса?