type Brand struct {...}

и append(brand, Brand{"Reebok", 4})

типа того

ну и brand уже есть []Brand https://play.golang.org/p/P6j7d7Q0_Fr

Привет

Обновился до го 11, vscode перестал делать autocomplete

с GO111MODULE случайно не игрался?

ну и brand уже есть []Brand https://play.golang.org/p/P6j7d7Q0_Fr

Спасибо большое за разъяснение

Спасибо большое за разъяснение

еще, если по какой-то странной причине надо анонимно структуры описывать, то можно вот так упороться https://play.golang.org/p/ypO34ltfgKJ

т.е. заново описывать спеку структуры каждый раз

но думаю, без явной нужды это может считаться плохим стилем

и задалбывает

Обновился до го 11, vscode перестал делать autocomplete

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

а почему у меня не поломался?

вернее - он поломался, но я перекомпилял все тулзы, и он починился

vscode сам предлагает, кстати, все перекомпилять

Там сломался автокомплит при определнных кейсах только вроде

Там сломался автокомплит при определнных кейсах только вроде

У меня везде, но я перекомпилил и всё заработало

настроить в main, а потом получать в хендлерах через zap.L()

Спасибо.

Привет! Есть ли среди присутствующих кто-то, кто использует echo как основной фреймворк для написания веб-приложений?

Хотелось бы послушать советы или посмотреть может быть репозиторий со структурой проекта Имею в голове собственную структуру, но допускаю, что в силу недостатка у меня опыта, она убогая получилась

У меня везде, но я перекомпилил и всё заработало

Обнаружил проблему с дебагингом

Мне это всё очень не нравится

Эхо не эхо - сути особо не меняет.

Эхо не эхо - сути особо не меняет.

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

И еще Когда приложение включает в себя какое-то АПИ, как вообще принято адекватно обрабатывать данные, которые в запросе приходят? я для каждого метода в апи создаю отдельную структуру типа type loginRequestBody struct { Login string `json:"login"` Password string `json:"password"` } После этого я получаю данные из запроса в эту структуру и передаю на обработку примерно так: data := new(loginRequestBody) if err := c.Bind(u); err != nil { return err } result := UserController.Login(data.Email, data.Password)

выглядит как полное убожество) можно это как-то разуменее делать?

Вечер добрый, мужики я тут оплату через stripe делал, но появилось нужда сделать проверку по 3д секюр. Кто такое делал ? Для меня просто вообще не понятно как проверить нужна ли проверка для карты пользователя, а если нужна то откуда получить ссылку для редиректа ...

Подскажите плиз кому не труда, заранее спасибо всем

выглядит как полное убожество) можно это как-то разуменее делать?

Ну можно объединить декларацию типа и создание переменной

А в остальном ничего не поменяешь осоьо

А в остальном ничего не поменяешь осоьо

Спасибо!

Есть такая ситуация: мы создаем юзера, есть метод из репозитория CreateUser, который должен создавать юзера в БД. Также этому юзеру будет присвоен айди, который потом надо будет вернуть. Нормально ли будет сделать так, чтобы передавать в метод указатель на userData и тот модифицировал добавляя ему значение в поле Id, либо же делать чтобы этот метод возвращал копию структуры с дополнительным необходимым полем? userData := models.User{ FirstName: req.FirstName, LastName: req.LastName, Email: req.Email } err = controller.db.CreateUser(userData)

id, err = controller.db.CreateUser(userData) а так, не?

id, err = controller.db.CreateUser(userData) а так, не?

Ну а если допустим он не одно поле должен добавить, а несколько? Такой вариант вряд ли подойдет

Есть такая ситуация: мы создаем юзера, есть метод из репозитория CreateUser, который должен создавать юзера в БД. Также этому юзеру будет присвоен айди, который потом надо будет вернуть. Нормально ли будет сделать так, чтобы передавать в метод указатель на userData и тот модифицировал добавляя ему значение в поле Id, либо же делать чтобы этот метод возвращал копию структуры с дополнительным необходимым полем? userData := models.User{ FirstName: req.FirstName, LastName: req.LastName, Email: req.Email } err = controller.db.CreateUser(userData)

Либо же тут вообще передавать в метод параметрами firstName, lastName, email и метод будет возвращать структуру? Хотя такой вариант мне кажется совсем плохим

Хм, func (p *TutChtoto) CreateUser(userData) (id, error) { ... return id, err }

Есть такая ситуация: мы создаем юзера, есть метод из репозитория CreateUser, который должен создавать юзера в БД. Также этому юзеру будет присвоен айди, который потом надо будет вернуть. Нормально ли будет сделать так, чтобы передавать в метод указатель на userData и тот модифицировал добавляя ему значение в поле Id, либо же делать чтобы этот метод возвращал копию структуры с дополнительным необходимым полем? userData := models.User{ FirstName: req.FirstName, LastName: req.LastName, Email: req.Email } err = controller.db.CreateUser(userData)

Взгляните на класические подходы и выберите. https://gist.github.com/codedokode/c4cbc4d7dc8e45ea074a ссылка конечно не связана с го, но описывает популярные подходы хоть немного наглядно

Есть такая ситуация: мы создаем юзера, есть метод из репозитория CreateUser, который должен создавать юзера в БД. Также этому юзеру будет присвоен айди, который потом надо будет вернуть. Нормально ли будет сделать так, чтобы передавать в метод указатель на userData и тот модифицировал добавляя ему значение в поле Id, либо же делать чтобы этот метод возвращал копию структуры с дополнительным необходимым полем? userData := models.User{ FirstName: req.FirstName, LastName: req.LastName, Email: req.Email } err = controller.db.CreateUser(userData)

Вообще вариант записывать ID в модель User в самой функции CreateUser более симпатичный и логичный ИМХО. Сам так делаю обычно.

Взгляните на класические подходы и выберите. https://gist.github.com/codedokode/c4cbc4d7dc8e45ea074a ссылка конечно не связана с го, но описывает популярные подходы хоть немного наглядно

Я выбрал шаблон Репозиторий, из того что вы скинули похож на него DataMapper

Только тогда нужна ссылка на userData

Вообще вариант записывать ID в модель User в самой функции CreateUser более симпатичный и логичный ИМХО. Сам так делаю обычно.

А смысл? Вернуть пустую структуру в которой лишь только ID? Он пишет юзера в базу, используя структуру, получить хочет его ID, ну так и нужно вернуть int и всё.

Не вернуть пустую структуру, а модифицировать текущую, указав в ней ID тем самым после вставки в БД. Но я оговорился уже, что для этого уже ссылка нужна

Я выбрал шаблон Репозиторий, из того что вы скинули похож на него DataMapper

Просто посмотрите как с таким подходом работают в го, это популярный подход

Есть такая ситуация: мы создаем юзера, есть метод из репозитория CreateUser, который должен создавать юзера в БД. Также этому юзеру будет присвоен айди, который потом надо будет вернуть. Нормально ли будет сделать так, чтобы передавать в метод указатель на userData и тот модифицировал добавляя ему значение в поле Id, либо же делать чтобы этот метод возвращал копию структуры с дополнительным необходимым полем? userData := models.User{ FirstName: req.FirstName, LastName: req.LastName, Email: req.Email } err = controller.db.CreateUser(userData)

репозиторий - это интерфейс к хранилищу. соответственно он достает оттуда юзера и его туда сохраняет. Поэтому save/store/push, но не create

репозиторий - это интерфейс к хранилищу. соответственно он достает оттуда юзера и его туда сохраняет. Поэтому save/store/push, но не create

Думал об этом сегодня уже

репозиторий - это интерфейс к хранилищу. соответственно он достает оттуда юзера и его туда сохраняет. Поэтому save/store/push, но не create

Тут у человека ж не в имени пробоема, а в возврате после создания результата

репозиторий - это интерфейс к хранилищу. соответственно он достает оттуда юзера и его туда сохраняет. Поэтому save/store/push, но не create

А как решить саму проблему то?)

Верни int, err из функции, не мучайся.

Хм, func (p *TutChtoto) CreateUser(userData) (id, error) { ... return id, err }

Верни int, err из функции, не мучайся.

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

А как решить саму проблему то?)

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

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

В смысле меняться?

А как решить саму проблему то?)

читал как это решается в ddd?

читал как это решается в ddd?

Нет, буду рад если поделишься ресурсом

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

По сути да

В смысле меняться?

Мыслями немного не туда повело, забей)

решается identity generator'ом, который либо генерит id на стороне приложения (uuid) либо достает следующий id из базы. Второй вариант геморный и явно через жопу.

решается identity generator'ом, который либо генерит id на стороне приложения (uuid) либо достает следующий id из базы. Второй вариант геморный и явно через жопу.

Почему? // InsertUser ... func (p *Handler) InsertUser(ChatID int64) (int, error) { var lastInsertID int t := time.Now() err := p.dbConn.QueryRow(`INSERT INTO users (chat_id, dt) VALUES($1,$2) RETURNING id;`, &ChatID, &t).Scan(&lastInsertID) if err != nil { log.Fatal(err) } return lastInsertID, nil }

решается identity generator'ом, который либо генерит id на стороне приложения (uuid) либо достает следующий id из базы. Второй вариант геморный и явно через жопу.

то есть SQL-запрос вида INSERT INTO ( name, .... ) VALUES ('petya') RETURNING id черезжопный априори?

упс. опередили))

Тогда нужно по вашей логике отказываться от int'овых PRIMARY KEY и переходить на GUID'ы

Ну вот в MySQL если я не ошибаюсь, ты вставляешь строку первым запросом, потом кто тоже вставляет строку сразу после тебя, и твой второй запрос на last_insert_id() вернет айди строки второго человека

Это Postgres умный и может вернуть что хочешь из вставляемой строки

ERROR: S client not available

Ребята, юзайте returning из базы, вы че тут придумываете??

решается identity generator'ом, который либо генерит id на стороне приложения (uuid) либо достает следующий id из базы. Второй вариант геморный и явно через жопу.

uuid как на замену автоматически генерируемого айди базой?

Ребята, юзайте returning из базы, вы че тут придумываете??

хочется поизвращаться

Почему? // InsertUser ... func (p *Handler) InsertUser(ChatID int64) (int, error) { var lastInsertID int t := time.Now() err := p.dbConn.QueryRow(`INSERT INTO users (chat_id, dt) VALUES($1,$2) RETURNING id;`, &ChatID, &t).Scan(&lastInsertID) if err != nil { log.Fatal(err) } return lastInsertID, nil }

я не понимаю, что тут у тебя за chatId и что ты вообще тут показываешь

uuid как на замену автоматически генерируемого айди базой?

да

я не понимаю, что тут у тебя за chatId и что ты вообще тут показываешь

Пусть будет не chatID, пусть будет firstName, это я из бота копипастнул.

да

Я так понимаю это распространенный подход?

Пусть будет не chatID, пусть будет firstName, это я из бота копипастнул.

давай у нас репозиторий будет работать с User, а не firstName

Ну окей, что меняет-то? Вернуть из базы id последней записи проще же, не?

Единственный косяк который я вижу, это что int закончится.

Ну окей, что меняет-то? Вернуть из базы id последней записи проще же, не?

репозиторий - это интерфейс к хранилищу. Не к базе. Хранилище может быть без автоинкрементных id.

меняем реализацию репозитория и наш код перестает работать, потому что id не возвращается

Единственный косяк который я вижу, это что int закончится.

Сомневаюсь, что у вас такие объемы, что он закончится

Ну, мало-ли, делит, инсёрт частый.

то что ты предлагаешь - это называется "текут абстракции". Ты репозиторий реализуешь так, как будто бы знаешь что он будет mysql

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

поэтому мы можем просто UserStore сделать как предлагаешь ты например. Либо репозиторий

Не, я делаю через модель, переписать только запросы в базу и всё. Вот по такой схеме https://habr.com/post/329582/

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

Мысль да, хорошая.

Почувствовал себя насильником? :-D

Почувствовал себя насильником? :-D

Более того, это мне моя девушка скинула. Которая в БГУИРе учится

насильница какая!

Программист теоретик, горе в семье

Откуда у них эти «шуточки»

Внизу доска, а сверху - "презентация"... Вобще, кажется, что материал лучше усваивается, если лектор это прямо тут же далает все на доске! Но так сложней готовиться к лекции, для лектора :(

Товарищи не подскажите как кильнуть time.Sleep(time.Until(nextExecute)) ? А то после CTRL+C приложение еще может минуту висеть пока SIGINT дойдет....? func SessionCleanupTask() { var quit = make(chan os.Signal) signal.Notify(quit, syscall.SIGHUP, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT) // kbdloss,ctrl+c,terminate,quit for { select { case <- quit: return default: nextExecute := time.Now().Add(time.Minute) time.Sleep(time.Until(nextExecute)) log.Println("peek: SessionCleanupTask") } } } func init() { go SessionCleanupTask() }

никак

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

А альтернативый способ сделать background таск с выполнением по времени или до сигнала?

или до таймаута в switch