Я не знаю питон, речь про go lang

можно, но это плохая идея

лучше открыть один раз при запуске приложения

А как потом это "прокидывать" в обработчики http?
Можете посоветовать репозиторий, где можно было бы посмотреть структуру? В голове не получается корректно сформировать

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

в пуле запросы последовательны или конкурентны? если в этот момент к АПИ стукнется 1000 запросов, то последний дольше всех будет?

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

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

Спасибо!

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

например так

package main

func main() {
                       db := newDB()
  gamesHandler := gamehdl.NewHTTPHandler(db)

  router := gin.New()
  router.GET("/games/:id", gamesHandler.Get)
  router.POST("/games", gamesHandler.Create)

  router.Run(":8080")
}

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

package main

func main() {
                       db := newDB()
  gamesHandler := gamehdl.NewHTTPHandler(db)

  router := gin.New()
  router.GET("/games/:id", gamesHandler.Get)
  router.POST("/games", gamesHandler.Create)

  router.Run(":8080")
}

1. То есть при запуске сервера выполняется 1 раз db.Open  а после указатель на пул передается в структуры пакетов которые планируют с ними работатб?
2. Условно при создании сервера - я могу прокинуть *sql.DB в некий пакет store с методами работы с БД (crud и прочие), а сам стор прокидывать в хендлеры, верно?

Всем привет! Я тут провел расследование по поводу работы планировщика Go.

1) Правильно ли я понял, что горутина при вызове io.Reader.Read переходит в режим ожидания, а значит ядро CPU может быть использовано другими горутинами?

2) Верно ли утверждение, если горутина начнет выполнять длительное вычисление, то остановить ее сможет только планировщик ОС?

Да и да

спасибо ребят)

Второе - с версии 1.14. до того никто не мог

1. да, передаем указатель на пулл соединений. это ресурс. в основном применяется этот ресурс в хранение и получение данных. часто эту логику реализуют в отдельной структуре - репозитории. репозиторий - сохраняет обновляет, возвращает данные, удаляет и там много чего. потом репозиторий используется в каких то сервисах, сервисы в хэндлерах. часто можно видеть такое в main

db := newDB()
br := newBookRepository(db)
bs := newBookService(br)
h := newBookHandler(bs)

2.да. как вариант

package db

....

var db   *sqlx.DB

func init() {
  db, err = sqlx.Open("postgres", url)
}

func GetConnection() *sqlx.DB {
  return db
}

 
но 2 вариант очень плохо, целиком из антипаттернов go

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

db := newDB()
br := newBookRepository(db)
bs := newBookService(br)
h := newBookHandler(bs)

package db

....

var db   *sqlx.DB

func init() {
  db, err = sqlx.Open("postgres", url)
}

func GetConnection() *sqlx.DB {
  return db
}

Благодарю за развёрнутый ответ.
Особенно про то что db это не коннект а пул