heavycharged
видимо только через Raw() делать..
heavycharged
И что будет по-другому через Raw()?
ты видимо не понял вопроса.
У меня есть структура City которая содержит в себе структуру State, связаны через city.state_id = state.id (One-To-Many). Мне нужно выбрать все города (не один, не LIMIT 1), при этом чтобы я указал слайс из городов в Find(&cities), и на выходе мог сделать так: city.State.Name, тоесть сканирование сделалось внутрь city.State.
Через Raw() это решится так:
for rows.Next() {
c := &City{
State: &State{}
}
if err := rows.Scan(&c.ID, &c.Name, &c.State.Name); err != nil {
log.Println(err)
continue
}
cities = append(cities, c)
}
heavycharged
ну можно и через Table().Select()... так как там есть Rows()
heavycharged
Хотел короче одним махом порешать.. :( пойду доку почитаю, может там нарою что-то.
Nikita
Хотел короче одним махом порешать.. :( пойду доку почитаю, может там нарою что-то.
Лучше скинь скрин диаграммы бд из датагрипа
heavycharged
https://i.imgur.com/L0mMeQn.png
heavycharged
как- то так диаграмма выглядит, обычная one-to-one связь. там ещё есть табличка со странами, но она не используется, так как все в рамках одной страны происходит.
heavycharged
просто создал на будущее, так как state должны были куда-то привязываться.
Kirill
интересно, у меня одного упала дока энсибла? 🤔
Aleksandr
как бы говорит, ночь с пятницы на субботу для других дел
heavycharged
думал сначала организовать такую структуру,
- bank
-- handler.go
-- model.go
-- view.go
- city
-- handler.go
-- model.go
-- view.go
- state
-- state.go
-- model.go
-- view.go
и было очень удобно, можно было делать так: city.All() - кратко и красиво. И знал же про циклический импорт, но не сообразил сразу что упрусь в него по итоге, когда city будет включать в себя state, а state включать в себя []City. Можно конечно вынести в отдельный пакет и сделать через alias. В итоге разнес по controller, models, views. Теперь model.AllCities(). Есть какие-то другие способы структурирования папок в проекте?
Kirill
думал сначала организовать такую структуру,
- bank
-- handler.go
-- model.go
-- view.go
- city
-- handler.go
-- model.go
-- view.go
- state
-- state.go
-- model.go
-- view.go
и было очень удобно, можно было делать так: city.All() - кратко и красиво. И знал же про циклический импорт, но не сообразил сразу что упрусь в него по итоге, когда city будет включать в себя state, а state включать в себя []City. Можно конечно вынести в отдельный пакет и сделать через alias. В итоге разнес по controller, models, views. Теперь model.AllCities(). Есть какие-то другие способы структурирования папок в проекте?
есть хак. пихаешь всё в internals, а из него наружу выкидываешь линки на методы
heavycharged
есть хак. пихаешь всё в internals, а из него наружу выкидываешь линки на методы
о, спасибо! вариант.. жаль только немного костыль :(
Kirill
костыль, конечно, но даст тебе твои city.All()
Vsevolod
думал сначала организовать такую структуру,
- bank
-- handler.go
-- model.go
-- view.go
- city
-- handler.go
-- model.go
-- view.go
- state
-- state.go
-- model.go
-- view.go
и было очень удобно, можно было делать так: city.All() - кратко и красиво. И знал же про циклический импорт, но не сообразил сразу что упрусь в него по итоге, когда city будет включать в себя state, а state включать в себя []City. Можно конечно вынести в отдельный пакет и сделать через alias. В итоге разнес по controller, models, views. Теперь model.AllCities(). Есть какие-то другие способы структурирования папок в проекте?
предлагаю ознакомиться с этой статьей. https://habrahabr.ru/post/269893/ и исходя из вашего приложения сформировать архитектуру.
Dmitry
предлагаю ознакомиться с этой статьей. https://habrahabr.ru/post/269893/ и исходя из вашего приложения сформировать архитектуру.
Не тратьте время на это. Ваш код превратится из Go-way в Go-wno.
Циклические зависимости; по несколько одинаковых интерфейсов в разных пакетах для одного объекта (структуры); сложности отладки; сложности поддержки кода, когда при добавлении одной функции, нужно будет изменять все интерфейсы; ошибки будете находить только на этапе компиляции, а потом много времени тратить на поиск интерфейсов.
Dmitry
я молчу про скорость работы!
интерфейсы замедляют работу в 6.5 раз, а там они будут абсолютно везде
Dmitry
я молчу про скорость работы!
интерфейсы замедляют работу в 6.5 раз, а там они будут абсолютно везде
https://www.darkcoding.net/software/go-the-price-of-interface/
🎉
я молчу про скорость работы!
интерфейсы замедляют работу в 6.5 раз, а там они будут абсолютно везде
То есть от интерфейсов желательно избавляться?
Dmitry
их вообще не нужно использовать до тех пока в них не будет необходимости.
Vsevolod
Все зависит от специфики приложения. И инструменты и архитектуру нужно применять в зависимости от вашей специфики.
Dmitry
Все зависит от специфики приложения. И инструменты и архитектуру нужно применять в зависимости от вашей специфики.
да, но "Чистая Архитектура" очень плохо ложится на Go.
Kirill
да, но "Чистая Архитектура" очень плохо ложится на Go.
что вместо нее юать посоветуешь?)
Kirill
в какую сторону смотреть
Vsevolod
да, но "Чистая Архитектура" очень плохо ложится на Go.
в чистом виде - да ) но в случае переиспользовании компонентов, наличия различных условий и БД, приходится выносить основную логику в бизнес-домен, а со остальными элементами общаться на базе интерфейсов.
🎉
Вот сейчас почитываю https://habrahabr.ru/post/329582/ это норм, ну если с middlewares?
Dmitry
мы делаем так
|- api
| |- <handlername_package>
| | |- handler.go (и всё что связанно с обработкой запроса)
| |- mux.go (указываем роуты и хендлеры к ним)
| |- server.go ( настройка сервера )
|- dal
| |- репозитории
|- пакеты с бизнес логикой
|- main.go
Kirill
есть у кого ссылка на хороший проект посмотреть в качестве примера?)
Никита
их вообще не нужно использовать до тех пока в них не будет необходимости.
Оки доки, а как быть с тестами тогда?
Dmitry
Оки доки, а как быть с тестами тогда?
писать :)
только БД плохо тестируются (тут вполне уместно использовать интерфейсы), в любых других случаях не замечал проблем.
Dmitry
тут важно понимать, что структура это не класс, это просто структура данных и какой то сложной логики она не должна нести
Никита
писать :)
только БД плохо тестируются (тут вполне уместно использовать интерфейсы), в любых других случаях не замечал проблем.
Только бд - это в случае если у вас небольшой сервис у которого из депенденси только СУБД. Если на горизонте появляется мало мальски СОА, то тут же возникают очереди, запросы в другие сервисы етц
Я к тому, что без интерфейсов получится протестировать малую долю приложения, на моей практике по крайней мере
Мое оценочное суждение)
Никита
Ну а чистая архитектура выглядит громоздкой и излишней примерно до момента внедрения второго транспортного слоя - того же рэббита
Dmitry
Do not define interfaces on the implementor side of an API "for mocking"; instead, design the API so that it can be tested using the public API of the real implementation.
почему бы сразу не использовать реальное API?
Никита
Ну и. Это же не закон, вполне удобненько позаимствовать пару идей оттуда не реаоизовавая дополнительный слой с драйверами, если не хочется
Никита
Do not define interfaces on the implementor side of an API "for mocking"; instead, design the API so that it can be tested using the public API of the real implementation.
почему бы сразу не использовать реальное API?
Окей, давай на примерах? СУБД, редис, микросервисы - как ты будешь использовать в тестах паблик апи?
Dmitry
🄽🄸🄺🄸🅃🄰
С большой буквы и камелькейс
🄽🄸🄺🄸🅃🄰
Поля структур
🄽🄸🄺🄸🅃🄰
Чтобы норм по Гошевски,
🄽🄸🄺🄸🅃🄰
И чтобы маошалилось
Никита
чего? :)
Я сделал утверждение, что не только бд не тестируется без интерфейсов, привел в пример зависимости от других сервисов, очередей или кэша. Ты в ответ кидаешь цитату со слова шьми почему бы не использовать реальное апи. Вот я и попросил примеры, как ты это видишь
Никита
а я наверное тебя)
Кстати буду признателен, если ты скинешь полистать про замедление в 6.5 раз
Dmitry
Кстати буду признателен, если ты скинешь полистать про замедление в 6.5 раз
https://www.darkcoding.net/software/go-the-price-of-interface/
Dmitry
а спорить в чате не буду))
Никита
а спорить в чате не буду))
Погоди, при чем тут спор?
Тут менее опытные товарищи спрашивают помощи, ты даёшь им некоторую информацию, т.е. хочешь поделиться ей. Но не хочешь пояснить как ты этой информацией пользуешься
Статейку читну, но как то очень подозрительно в статье идёт речь о пустом интерфейсе.
Никита
Я не похоливарить зашёл. Мне в конце концов тоже интересно)
Dmitry
Погоди, при чем тут спор?
Тут менее опытные товарищи спрашивают помощи, ты даёшь им некоторую информацию, т.е. хочешь поделиться ей. Но не хочешь пояснить как ты этой информацией пользуешься
Статейку читну, но как то очень подозрительно в статье идёт речь о пустом интерфейсе.
не важно что пустой, при каждом обращении к интерфейсу вызывается функция runtime.convT2E она то и замедляет работу.
ещё дополню, что из за этой же функции, другие функции вообще не инлайнятся.
Dmitry
правда пруфов не будет... можно самому написать простой пример, и посмотреть в дизассемлере
Никита
Ты отвечаешь не на тот вопрос. Ты скинул линк, я прочту все что автор указал, сам пойму этот дзен)
Artem
правда пруфов не будет... можно самому написать простой пример, и посмотреть в дизассемлере
смотреть это не в дизассемблере нужно, а в профилировщике, более того, сколько раз подобное слышал, а на практике это далеко не самое узкое место в програме, а куда сиьней тормозятпользовательские алгоритмы. Более того скорость работы -это не главное и далеко не все приложения заметят потерю производительности если начнут использовать интерфейсы.
Artem
лучше покажите хоть один пример реального кода, в котором переход от интерфейсов дал профит
Антон
подскажите, я вот просто использую http,стандартные роуты. Но во всех видео англоязычных и пакетах на гитхабе, используется какой-то Mux, что это и зачем? критически ли важно изучать это и тд?
Artem
да критически это мультиплексор
Vasily
подскажите, я вот просто использую http,стандартные роуты. Но во всех видео англоязычных и пакетах на гитхабе, используется какой-то Mux, что это и зачем? критически ли важно изучать это и тд?
лучше разобраться
вы уже используете mux в стандартном http, так что у вас не уйдёт много времени на изучение
Andrey
Есть вопрос по поводу общения сервисов. Задача в том, как организовать общение сервисов в кейсе -
1 сервис - запрос данных с внешнего сервиса.
2 сервис - делает множество запросов, используя 1 сервис и отдает данные внешнему пользователю.
Кейс - сервис 2, создает событие запроса данных, сервис 1 получает событие, скачивает данные и должен отдать сервису 2
Вопрос в том, как лучше сделать такое общение?
В лоб решение, можно сделать дополнительное поле reply_to, подписаться на него 2 сервисом и потом 1 сервис ответит нам.
Roman
Andrey
и в чем проблема? какой объем данных? какие ограничения?
Интересно, как еще можно и лучше сделать. Данных мало и на самом деле, это все будет использоваться в браузере и на js.
Andrey
и главное, это удобство использование и расширения
Stanislav
лучше покажите хоть один пример реального кода, в котором переход от интерфейсов дал профит
такого не будет, скорее всего 🙂
Stanislav
а вот путаницы в логике может возникнуть дофигища
Vitaly
Все привет! А что сейчас юзают в Golang сообществе для управления зависимостями? godep?
randle
dep
Michael
Go's dep 😊
Vitaly
А при одновременной работе с несколькими проектами проблем нет, если dep используешь?
Vitaly
Я тут в одной презентации от июля 2017 увидел, что только в планах multi-project workflow
heavycharged
вроде он тянет в папку vendor, вот и все. везде будет локальная копия. 10 проетков - 10 локальных копий.
heavycharged
но могу ошибаться
heavycharged
а тебе нужно что-то вроде npm с флагом global?
Vitaly
а тебе нужно что-то вроде npm с флагом global?
не, мне именно так и нужно, как ты описал, спасибо
Максим
Добрый вечер, подниму заезженную тему. Кто как делает SQL миграции? Уже задавал этот вопрос, но так и не нашёл адекватного решения.
На данный момент использую pop и его компонент soda в качестве orm и миграций соответственно.
Может есть более адекватные решения? Или проще самому написать скрипт, который будет фиксировать миграцию?