Oleg Shevelev: ok, давайте о теории и напильниках. Собственно чтоб разобраться что тут и как нужно понимать "механику" работы между приложением и СУБД. С одной стороны понятно что автор go-database-sql.org всю жизнь писал скрипты на Perl и PHP для облегчения работы DBS, с другой стороны не очень, т.к. во внутренностях тогоже MySql он должен разбираться чуть более чем полностью.
Дак вот: между приложением и СУБД устанавливается соединение, когда мы пишем SELECT * FROM dev_method WHERE name=? мы как бы говорим серверу о своем намерении что-либо сделать, он "проверяет" данный запрос и смотрит что делать дальше; плейсхолдер "?" для MySql говорит о том что для данного запроса будут и данные, поэтому он "выбирает их и вставляет в бд", это может быть 1 набор или n-е количество (prepared), все ок. Иньекция - это изменение того самого нашего "намерения", если данные "вставляются" на стороне нашего ПО, то можно "переписать" запрос на валидный с точки зрения СУБД и дропнуть там все на что прав хватит. Поэтому: данные отдельно/ запрос отдельно - хорошо, вставлять в запрос данные - плохо.
О напильниках:
Опятьже автор жил в мире 1 соединения с бд на всю логику его приложения, которое последовательно что-то там делало, одняко в Го - сюрпрайз, соединение с сервером не закрывается после каждого запроса.
"Просто и на пальцах":
Го пулит соединения с СУЬД, если принудительно соединение не закрывать то оно возвращается в пул.
Сюрпризный момент:
db.Query/Exec etc... выбирают соединение из пула, поэтому:
db.Begin()
db.Exec()
db.Commit()
вполне себе могут быть выполнены в разных соединениях что как бы все поломает, но, как написанно в документации делать так не стоит, а стоит "закрепить" за собой соединение до заврешения обработки пачки бизнес логики
tx:= db.Begin() // открываем транзакцию, объект db в tx закрепляет за собой соединение
tx.Query()/Exec()/etc...
tx.Commit()/Rollback() / закрываем транзакцию и возвращаем соединение в пул
Александр Василенко: смотря какие задачи, где-то Go уже заменил C/C++ etc, где-то он их заменить не сможет. Опятьже что считать системными/железячными штуками, через тотже syscall он вполне себе может железяками поуправлять )
lelvisl: ну у вас же не задача на нахождение пересечения 2-х массивов, собственно цель то этого всего в чем, зачем вам искать пересечение в 500к слайсов ?
Salavat Sharapov: если не через браузер - все равно, в подключении указывать что валидность сертификата не проверять , если через браузер - он скажет что сертификат невалиден
чтоб таким образом не "отстрелить себе ногу", да и вообще использовать PostgreSQL+json используйте jsonb , в отличии от json он понимает что в него пишут
A. Shpak: вот смотрите, у вас есть проект который нужно поддерживать, что для этого дает Го:
стандарты кодирования (gofmt)
система документирования (godoc)
тесты/бенчмарки/покрытие тестами
система сборки (включая кросс-компиляцию и поддержку вендоров (вендоры с 1.5) )
профайлинг (pprof/trace/race detector)
и т.д.
Это никак не относится к языку, но это и есть Го ;)
Владимир: и, чтоб не забивать голову, у вас в системе жило 2 компилятор:, перый поставленный через apt-get install, второй "ручками", сборка осуществлялась первым )
ну и go version xgcc (Ubuntu 4.9.1-0ubuntu1) 4.9.1 linux/amd64, а дожно быть go version go1.5 linux/amd64, так что он был не просто не 1.5, а совсем даже не Go ;)
Вот, значит зависимости есть. Соответственно на debian нет каких-то из них (а особенно в exe ))
Вам нужно собрать бинарник статическим, чтоб этих зависимостей не было
пробуем
go build --ldflags '-extldflags "-static" -s' file.go
смотрим ldd file , должно быть not a dynamic executable
если, вдрег не помогло, идем в папку с установленным Go, в ней в src запускаем CGO_ENABLED=0 ./make.bash
Дак вот: между приложением и СУБД устанавливается соединение, когда мы пишем SELECT * FROM dev_method WHERE name=? мы как бы говорим серверу о своем намерении что-либо сделать, он "проверяет" данный запрос и смотрит что делать дальше; плейсхолдер "?" для MySql говорит о том что для данного запроса будут и данные, поэтому он "выбирает их и вставляет в бд", это может быть 1 набор или n-е количество (prepared), все ок. Иньекция - это изменение того самого нашего "намерения", если данные "вставляются" на стороне нашего ПО, то можно "переписать" запрос на валидный с точки зрения СУБД и дропнуть там все на что прав хватит. Поэтому: данные отдельно/ запрос отдельно - хорошо, вставлять в запрос данные - плохо.
О напильниках:
Опятьже автор жил в мире 1 соединения с бд на всю логику его приложения, которое последовательно что-то там делало, одняко в Го - сюрпрайз, соединение с сервером не закрывается после каждого запроса.
"Просто и на пальцах":
Го пулит соединения с СУЬД, если принудительно соединение не закрывать то оно возвращается в пул.
Сюрпризный момент:
db.Query/Exec etc... выбирают соединение из пула, поэтому:
db.Begin()
db.Exec()
db.Commit()
вполне себе могут быть выполнены в разных соединениях что как бы все поломает, но, как написанно в документации делать так не стоит, а стоит "закрепить" за собой соединение до заврешения обработки пачки бизнес логики
tx:= db.Begin() // открываем транзакцию, объект db в tx закрепляет за собой соединение
tx.Query()/Exec()/etc...
tx.Commit()/Rollback() / закрываем транзакцию и возвращаем соединение в пул
Все просто и логично