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

но как я понимаю главный - это макс кол-во открытых коннектов

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

потом наверное идет max idle

если их сделать малым, то пул может начать закрывать неиспользуемые, а потом по необходимости опять открывать новые, так что будет постоянный connect/close

поправтье меня, кто в теме, если я не прав

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

но подозреваю, что его можно выставить достаточно большим

народ может кто сталкиался с формированием динамических запросов к БД

типа по времени в зависимости от полученных данных, для времени пришли 2 даты нужно делать Between date1 and date2, одна дата >date1 или <date2, или вообще нет выборки по дате

так это в where можно все уложить

в виде date1 is not null and date2 is not null and ... between date1 and date2 or date1 is not null and date2 is null and ... > date1

и тд

а может есть что то типа where(map[string]interface{}....

просто длинный запрос не очень понятный выйдет

ну тогда надо начать с того, что за орм)

сорри

gorm

с gorm не работал, но судя по докам, там между парами ключ-значение для map работает как AND

да

так вот проблема как эти условия для дат собрать

вроде как можно функцию написать которая будет разруливать эту логику, но как это все сложить в кучу

можно что- типа b.Where("name = 'jinzhu'").Or(map[string]interface{}{"name": "jinzhu 2"}).Find(&users) попробовать

каждый отдельный случай в map обернуть попробовать

возможно прокатит, но сейчас времени нет это проверить

ок, спс за идею

Вопросец конечно...

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

или два канала, один для даты, другой для quit и других сообщений

грубо var c chan EventStruct или var cControl chan bool var cData chan string

@onokonem что больше go way ?

зачем для quit бул? туда же пустую структуру можно передать

часто в примерах используется вариант с quit channel

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

если только для выхода, то можно один канал и закрывать его при выходе. А если ещё какие-то сообщения, то можно и несколько каналов. На самом деле не понятно, что значит "лучше"?

если только для выхода, то можно один канал и закрывать его при выходе. А если ещё какие-то сообщения, то можно и несколько каналов. На самом деле не понятно, что значит "лучше"?

как по go way правильнее

как по go way правильнее

Так, как лично тебе удобнее.

грубо var c chan EventStruct или var cControl chan bool var cData chan string

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

а если еще системные события там?

Так, как лично тебе удобнее.

мне удобно называть так переменные DB_Connection, но это не правильно)

ну в смысле всякие "ендект" и прочие

не ведут к выходу но отчитаться по ним надо

Ребята, привет! Вы люди знающие.. помогите хрупкой девушке и по совместительству рекрутеру IT-компании=) Где в телеграмме есть чат, в котором можно разместить вакансию о поиске GO-разработчика? Спасибо заранее за помощь и отзывчивость?

а если еще системные события там?

еще канал и селект по ним

select, ждущий данных из нескольких каналов кушает больше процессора. Поэтому если производительность не критична, то делай так, как удобнее. Если критична: старайся больше одного канала не слушать.

ну такое...

просто три канала это три парамса в функцию

у меня сейчас есть subscrive(c chan string)

внутри гоурутина крутиьтся

select, ждущий данных из нескольких каналов кушает больше процессора. Поэтому если производительность не критична, то делай так, как удобнее. Если критична: старайся больше одного канала не слушать.

А?!

ну и ты будешь слушать по структуре, а потом парсить ее?

ну это один из вариантов

пока не выбрали вот

Ребята, привет! Вы люди знающие.. помогите хрупкой девушке и по совместительству рекрутеру IT-компании=) Где в телеграмме есть чат, в котором можно разместить вакансию о поиске GO-разработчика? Спасибо заранее за помощь и отзывчивость?

https://t.me/golangjob

Оптимизация без профайлера - это пионерский подход

Оптимизация без профайлера - это пионерский подход

а ты что думаешь? ?

три канала под каждый чих

или один с структурой

Ребята, привет! Вы люди знающие.. помогите хрупкой девушке и по совместительству рекрутеру IT-компании=) Где в телеграмме есть чат, в котором можно разместить вакансию о поиске GO-разработчика? Спасибо заранее за помощь и отзывчивость?

Можно даже тут, если внятнач и с вилкой

(Данные, События, Выход)

три канала выходит

https://t.me/golangjob

Спасибо!

три канала под каждый чих

Три.

Спасибо!

https://t.me/golangjobfeed

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

А?!

Истинно говорю, медленее.

ну мы больше про гоувей

Истинно говорю, медленее.

опасно опасно ?

(Данные, События, Выход)

ты можешь еще на 2 функции раскидать

Истинно говорю, медленее.

Сильно? В масштабах всего приложения?

Сильно? В масштабах всего приложения?

Нет конечно. Ещё медленный select ожидающий, а не ожидающий - быстрый.

(вообще, каналы медленные, это правда. Но померять это можно только в вакууме)

Сильно? В масштабах всего приложения?

Возможно, что если сортировку на каналах сделать, то будет заметно. Там ведь только копирование данных. Оно вполне будет сравнимо с ожидающим select-ом.

Сортировка? На каналах?

(вообще, каналы медленные, это правда. Но померять это можно только в вакууме)

var dataChannel chan string var controlChannel chan string // ну для примера var quit chan driverOne.Subscribe(controlChannel, dataChannel, quit) driverTwo.Subscribe(controlChannel, dataChannel, quit) for { select { case data := <-dataChannel: fmt.Println("received data", data) case control := <-controlChannel: fmt.Println("received command", control) case <-quit: break default: fmt.Println("no activity") } }

я как понимаю вы про что-то типо такого

не очень конечно выглядит...

зы: опечатки

А зачем тут дефолт?

ну так было в примере

пофиг можно и не

Не пофиг

В этот дефолт нужен слип, или он будет проц жрать

ну в дефолт я вообще с трудом понимаю когда попадает

первая итерация... он читает канал один

вторая итерация... первый канал не имеет данных, странно что он не wait сделал

по идеи он должен был заплипнуть на case data := <-dataChannel:

В том то и суть, что select с default не будет лочиться. Попробует забрать данные из каждого кейса -> на данный момент времени ни с одного кейса не получилось вычитать -> выполняется default

придет @onokonem и спасет нас ?

в дефолт попадает когда ниодин из case не сработал.

а это как?

в коде выше цикл будет постоянно крутиться. Без дефолта он будет ждать, пока придут данные в один из каналов.

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

это как

for { value := <- channel }