The build will currently fail, as I haven't integrated the go-sqlite3 package inside the source tree.

@shlomi-noach This is going to be great, thanks for this. Let me know if you need an extra hand to test this. I am more than happy if I can help.

At this time orchestrator works with sqlite backend. I took the brute-force approach for converting MySQL dialect into sqlite3 dialect via regular expressions; I had to rewrite many queries where this was not achievable.

Many of these queries have now been simplified (which is good), and some have been broken into app logic (which is a pity).

The changes in no way suggest a generic translation mysql->sqlite. I just wanted to get warmed up to start testing functionality.

I'm proceeding to back-test that the rewrites work with mysql (I tested each individually, but haven't run a comprehensive check).

Will certainly need better testing method for this.

Next on this PR:

• make the integration tests work on sqlite, locally
• make the integration tests work on sqlite on janky (our testing suite)

I've been spending far too many hours on this. Perhaps someone can come up with a magic solution?

This PR is using https://github.com/mattn/go-sqlite3: sqlite wrapping for golang. The package contains a C file which compiles via cgo and is slow to compile (adds some 20-25 seconds compilation time).
A quick local win is to run go install github.com/mattn/go-sqlite3 ; subsequent runs will just use the package found on $GOPATH/pkg/darwin_amd64/github.com/mattn/go-sqlite3.a.

However the problem is this: I wish to incorporate this package under the vendor/ directory of this repository; such that anyone who clones github.com/github/orchestrator gets sqlite3 automatically, no external dependencies.
That also works -- with the problem that go now insists to compile the sqlite3 package every time I issue a go run.... I'm unable to tell go to use a .a package file within my own repository.

I tried:

• Adding pkg/darwin_amd64/github.com/mattn/go-sqlite3.a in repo path, using go build -pkgdir=pkg/
• Adding pkg/... under vendor/, under vendor/github.com/mattn/go-sqlite3, under practically any folder I thought would make sense
• Using binary-only packages

I realize the .a package depends on the exact golang version that compiled it -- it's fine that I would need to compile via cgo once , and that any user would have to do the same once, but having these extra 20-25 seconds for every compilation/run is too painful.
Does anyone have any suggestion?

merged #75 which solves dependency issue

#97 was based on this PR and has been merged.

Now this PR adds:

• Actually importing github.com/mattn/go-sqlite3
• Using sqlite3 in tests
• Including sqlite3 in vendor. That part I'm still looking at. Will examine golang 1.8's plugins.