...
At the time of this writing, CockroachDB is several hundred thousand lines of Go code, plus a smattering of C++ and TypeScript. Especially if you've never worked with Go, this can be daunting. This section is a whirlwind tour of what lives where, but you shouldn't expect all this information to permanently sink in until well after your first month.
First things first
Since CockroachDB is open source, most of the instructions for hacking on CockroachDB live in this repo, cockroachdb/cockroach. You should start by reading the top level of this section of the wiki.
...
cockroachdb/docs, which houses the code behind our user-facing documentation at cockroachlabs.com/docs. At the time of writing, our stellar docs team handles essentially all documentation.
cockroachdb/examples-go, which contains small, self-contained Go programs that exercise CockroachDB via the PGWire protocol. You're likely to hear most about block_writer, which writes uniformly random values into a table, and photos, which simulates a more-realistic workload of a photo-sharing site, where some photos and users are orders of magnitude more popular. The other example programs are of a similar scope and purpose, but block_writer and photos are deemed important enough to run constantly against our production clusters.
cockroachdb/loadgen, which contains the next generation of CockroachDB load testing. These include the industry-standard TPC-H and YCSB benchmarks (Google for details), as well as kv, version of block_writer that can target databases other than CockroachDB.
cockroachdb/examples-orms, which showcases ORMs a toy API that uses an ORM to prepare its responses in several different languages.
...
examples-orms, which showcases ORMs a toy API that uses an ORM to prepare its responses in several different languages.
Most of the remaining repositories under the cockroachdb organization are forks of existing Go libraries with some small, Cockroach-specific patches.
...
$ make test PKG=./pkg/rest/of/pathIs there a Go debugger?
Not a good one, sadly. Most of us debug single-cluster issues by littering log.Infofs throughout relevant files.
On Linux, GDB is supposedly reasonably functional; on macOS, building LLDB from source also yields a reasonably-functional debugger. Come talk to Nikhil if you think you'd find this helpful, and we can work on codifying the steps.Yes! It's called delve.
You can use delve on its own, but the easiest way is to use it via Goland. Goland is a Jetbrains IDE for Go. It has built in support for delve, and will "just work" if you click the standard debug buttons, set breakpoints, etc.
Do note that the debugger can be somewhat slow on live clusters. It may be easiest to use printfs, log.Infof, and so on, depending on what you're trying to do. Use your judgement!
If you're debugging an issue that spans several nodes, you 'll want to look into "could consider using our distributed tracing. " Ask your Roachmate to either walk you through OpenTracing/LightStep or point you at someone who can.
...