id=1,2,3, а в базе есть только id=1,2 ?
Конечно будет. Особенно если это для приложения “Найди партнёров чтобы сообразить на троих”! Ведь найдено только 2… errors.New(“Извините, компания не найдена. Придётся сегодня на работу…”)
вообще такая логика обычно и преполагается, но если нужно гарантировать точную связь с запросом можно вернуть map[int]User* и если по айдишнику ничего не нашлось - рисовать nil
ну или клиент может сам сравнить [1, 2, 3] с тем что вернулось [1, 2] и понять что чего-то не хватает
Если это в usecase то ошибка это или нет решает разработчик в зависимости от задачи, если это репозиторий, то для базы это нормальное поведение, «ты просил поискать [1, 2, 3] вот смотри что я нашла, дальше что с этим делать решай сам..»
совсем не факт, куча вариантов. Вернуть только те что есть и пусть потребитель разгребает, вернуть что есть + добавить поле notfound с ненайденными айдишниками, ничего не возвращать и рейзить ошибку. Нет контекста, чтобы давать одно решение как правильное
Зачем тут указатель?
будем считать что вкусовщина, без бенчмарка на конкретном коде не могу сказать что будет быстрее работать
Дело не в бенче. Не нашлось - нет ключа в мапе
а если нашлось то указатель на найденный объект
Зачем указатель?
указатель, или сам объект на стеке, без разницы. любой удобный способ получить найденный объект
Чем map[int]User хуже?
написал же выше - вкусовщина. в зависимости от контекста тот или иной вариант может быть предпочтительнее для конкретной задачи
Так а чем лучше может быть? Вот у тебя map[int]*User, ключ есть, а значение nil
да, я был не прав, сделал пару бенчмарков и получилось что использование указателей не дает значимого прироста производительности https://gist.github.com/chistopat/a3b2c664a82681a7f3aeacea6a20609e интересно почему так в go это работает
Потому что мапа - это ссылочный тип
1. юзер очень маленький, чем больше будет юзер тем выгоднее ссылки 2. много мусора оставили и тестите по факту не то
Обсуждают сегодня