пишем result, err := db.Query('INSERT INTO table_name (data_field1, date_field2) VALUES('DATA1', DATA2)') и ждем, что в result будет лежать что-то с айдишником вставленной записи внутри

пробуем с мускулем - все ок

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

потому что для него запрос должен выглядеть так INSERT INTO table_name (data_field1, date_field2) VALUES('DATA1', DATA2) RETURNING id

сама идея скормить DAO инициализированное соединение с базой - норм

создал sql.Connection и засунул в конструктор DAO

при этом DAO для мускуля в конструктор хочет sql.Connection

ну окей, а где само дао иницилизируется?

в main?

а DAO для файла-в-котором-хранится-все вполне может захотеть os.File

а то и io.ReadWriter

ну окей, а где само дао иницилизируется?

как решишь, так и будет

оно понятно, что и постгре, и мускуль, и мс-скуль, один хрен, будут юзать sql.DB

ну как вариант вижу в пакете db (моем пакете) просто сделать по 1 функции на каждую бд с инициализацией, но возращать уже готовый коннект

в DAO отдавай sql.DB

func NewMysqlDriver() *sql.DB { } func NewMongoDbDriver() *mongo.Session { }

и в майн получится что-то

и это в том случае, если у тебя реализация DAO поверх РСУБД

mysql := db.NewMysqlDriver() mongo := db.NewMongoDbDriver()

(параметры забыл, но это пример)

ну почему драйвер то(((

в main тогда (абстрагируясь от неудачных названий) mysql := db.NewMysqlDriver() myAwesomedao := dao.NewAwesomeMysqlDAO(mysql)

а потом уже с этим живи)

просто мы тогда хедлер прибиваем к конкретному дао выходит

с чего это

не прибиваешь ты ничего, если твое дао - это интерфейс

вот DAO и должно тебя абстрагировать от источника данных

у меня конечно дао больше от домена зависит чем от источника ?

есть бизнесовый пакет user и там есть dao

дальше у тебя type UniversalDAO inteface { Create(...) ... Read(...) ... } func NewHandler(dao UniversalDAO) {...}

ну CRUD может и не хватить

и в мейне: mysql := db.NewMysqlDriver() myAwesomedao := dao.NewAwesomeMysqlDAO(mysql) logic := packageName.NewHandler(myAwesomedao)

ну CRUD может и не хватить

а вот чо ты от своего дао хочешь - это исключительно твой головняк

зачем в мейне вообще вы это делаете все?

в мейне стартует viper командный парсер, внутри комманды живет кастомный сваггер сервер, в который принудительно накормлены хедлеры ( по умолчанию там просто коллбеки в файле поправить по живому)

на соседнем проекте вообще не парились и тупо все в callback реализовали

полотно на over9000 строк

жуть какая-то

ну я хоть как то пытаюсь это выправить

попробуй глянуть это https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

да там автогенеруемый сваггер сервер уже "чистая архитектура"

кто его писал руки бы оторвать

эти вывод в лог из файла который do not edit

Помогите понять для чего https://godoc.org/gopkg.in/mgo.v2#Collection.EnsureIndexKey

да там автогенеруемый сваггер сервер уже "чистая архитектура"

может лучше graphql?

это следующий этап

будем делать graphql поверх restapi

отдельным прокси сервисом

зачем в мейне вообще вы это делаете все?

если у приложухи одно соединение с одной конкретной базой данных - почему бы и нет? Не городить же serviceProvider заради одной записи?

если у приложухи одно соединение с одной конкретной базой данных - почему бы и нет? Не городить же serviceProvider заради одной записи?

две-три бд там

в одном приложении

а приложение одно?

да там автогенеруемый сваггер сервер уже "чистая архитектура"

Может результат не в ту дырку суют?

а приложение одно

но бинарников три ?

и базы между ними шарятся?

http апи, консоль "крутилка" и утилита

базы они юзают одинаковые

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

заради 3 дб-коннектов сервис-провайдерами заниматься, имхо, все еще рано

ну я и предложил тупо фабрики положить в отдельный пакет

будем делать graphql поверх restapi

Жесть

Жесть

там легаси апи еще есть, их трогать нини

ну я и предложил тупо фабрики положить в отдельный пакет

ну тип того

хотя щаз понабегут адепты

и скажут что все плохо

ERROR: S client not available

ну тип того

а с логированием как быть?

а с логированием как быть?

logrus, например

хорошая штука

у меня прикручен github.com/sirupsen/logrus туда, не внутри же его вызвать фабрики

смотри, есть такая штука, init()

если в пакадже main есть init(), оно выполнится ДО main()

я знаю про это

в нем инициализируй логгер, и норм

я про сами вызовы

а что с вызовами не так?

вот внутри фабрики db.NewMongoDb() у меня что-то сломалось

тут джва путя

либо ты имеешь синглтон-логгер

который глобальный

я либо могу внутри ее использовать logrus, либо вернуть стандартную ошибку

а потом по if вызвать уже логрус

хотя... наверно так и сделаю

параметры в main в любом случаи будут доступы (мне они нужны в консоль)

либо у тебя есть type Logger interface, а сигнатура метода db.NewMongoDB(logger Logger) ...

а еще у тебя есть такая штука - именованный импорт

не про импорты вопрос!

а про "глобальное" использование библиотек

func NewMongoDriver(host string, port int, login string, password string, database string) (*mgo.Session, error) { .... if err != nil { return nil, errors.New("can't connect") } }

а дальше в main уже обработать можно

смотри, ты пишешь со стандартным логгером. У логруса сигнатура пакета с ним совпадает. Тебе тупо в начале нужных пакетов вместо import "log" нужно написать import log "путь до логруса"

смотри, ты пишешь со стандартным логгером. У логруса сигнатура пакета с ним совпадает. Тебе тупо в начале нужных пакетов вместо import "log" нужно написать import log "путь до логруса"

сама идея писать в лог из пакета - утопична

можно в мейн, а можно в ней самой в лог кинуть

сама идея писать в лог из пакета - утопична

зато хорошо сказывается на всяческих импортах и автотестах, например...

но вообще, да, достаточно смутная затея

короче, работа с логами - весьма отдельный философский вопрос

для тестов надо везде юзать Dependency Injection

что бы можно было замокать либу