Engine instances as part of a massive mapreduce data pipelining job. Turns
out that fundamentally this has to be done through the sockets service
https://developers.google.com/appengine/docs/go/sockets/reference . Despite
this theoretically feasibility, it turns out that the current database/sql
package as well as related drivers do not play well with the interface
exposed by the sockets service yet. To solve this, I have put in some
efforts in https://github.com/lib/pq/pull/287 to at least attain a workable
solution for our case. However, I believe it would be even better if the
standard database/sql could naturally support such App-Engine-like use
Technically speaking, the main problem from my point of view is how to make
the database/sql package
when it starts to use a net.Conn. Looking at code, it seems that the safest
place to do this is in http://golang.org/src/pkg/database/sql/sql.go#L624 .
However, implementation wise, I am not sure how the database/sql package
should expose this interface; should it expose it as a general callback
that is done after DB.conn(), something similar to the Dial function in
http://golang.org/pkg/net/http/#Transport or as something else at the
Without doubt, this same problem is something the native appengine/cloudsql
package needs to solve, too. However, looking at the
, it seems that appengine/cloudsql package is taking advantage of some
internal shortcut that is not documented. I wonder is it possible for
someone to explain the details of this shortcut?
I wonder has anyone done something similar before on App Engine, and if so
is it possible to share your solutions? What do you think about this idea
of extending the standard database/sql to support some sort of low level
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.