Example code for basic Call and Prepare/Flush.#178
Example code for basic Call and Prepare/Flush.#178jamesgraves merged 3 commits intocockroachdb:masterfrom jamesgraves:client_examples
Conversation
client/client_test.go
Outdated
There was a problem hiding this comment.
Could you switch to "//" for line comments? See
http://golang.org/doc/effective_go.html#commentary
Go provides C-style /* */ block comments and C++-style // line comments. Line comments are the norm; block comments appear mostly as package comments, but are useful within an expression or to disable large swaths of code.
|
LGTM. Were you planning to do transactions in a follow on example? |
|
Yes, I'll work on transactions next. I'll also put in some comments at the start of each example, make the other suggested changes, and update this pull request. |
Example functions for a simple Put & Get using Call(), Prepare() & Flush(), and then RunTransaction(). Each example is self-contained, and includes the server setup/teardown. This makes the code closer to what would be used in an actual client program. Named all examples so that they will appear in the correct section of the documentation. The Prepare() & Flush() is a bit long because we have to create the values we are later scanning for. All the examples have been updated to match the coding style and fix other issues. Prepare/Flush example now runs multiple scans for sub-ranges of the keys in parallel.
|
I've rebased onto the current master, and made the changes we've discussed. Also added the transaction example. |
client/client_test.go
Outdated
There was a problem hiding this comment.
Sorry to be so anal, but: No double whitespace after dot. There's a vim setting for that.. I can't remember it now though.
|
Cool, good stuff. Thanks @jamesgraves! |
|
LGTM |
|
Made the changes, and just pushed each of them separately. Should I squash and re-push, or do you normally do that when you merge the pull request? |
|
Just go ahead and merge the request as is--that's what I do anyway. |
|
I like to bundle my commits up a little bit but really we have no rules for it, so just do common sense. Just merge it (Spencer is giving you perms) |
|
I've invited you to the team. Happy merging! |
Example code for basic Call and Prepare/Flush.
|
Thanks for the invite! I just merged it as-is this time. |
|
Thanks for contributing. I actually like the unsquashed commits. But totally up to you. |
We have been seeing long startup times which disappear spontaneously. During a
restart of the beta cluster, the following goroutine was observed, which suggests
that we were spending a lot of time GCing replicas on startup.
engine ??:0 _Cfunc_DBIterNext(cockroachdb#324, cockroachdb#323, 0, 0, 0, 0, 0, 0, 0)
engine rocksdb.go:1135 (*rocksDBIterator).Next(cockroachdb#235)
storage replica_data_iter.go:104 (*ReplicaDataIterator).Next(cockroachdb#316)
storage store.go:1748 (*Store).destroyReplicaData(#109, cockroachdb#317, 0, 0)
storage store.go:841 (*Store).Start.func2(0x101b, cockroachdb#300, 0x36, 0x40, cockroachdb#301, 0x36, 0x40, cockroachdb#315, 0x3, 0x4, ...)
storage store.go:734 IterateRangeDescriptors.func1(cockroachdb#306, 0x40, 0x41, cockroachdb#307, 0x92, 0x92, cockroachdb#341, 0, 0x186c, 0x4000, ...)
engine mvcc.go:1593 MVCCIterate(cockroachdb#329, #68, #47, #81, cockroachdb#232, 0x9, 0x10, cockroachdb#233, 0xb, 0x10, ...)
storage store.go:738 IterateRangeDescriptors(cockroachdb#330, cockroachdb#196, #47, #81, cockroachdb#195, #179, #110)
storage store.go:867 (*Store).Start(#109, cockroachdb#330, cockroachdb#196, #179, #185, 0x1)
server node.go:405 (*Node).initStores(#78, cockroachdb#330, cockroachdb#196, #98, 0x1, 0x1, #179, 0, #55)
server node.go:330 (*Node).start(#78, cockroachdb#330, cockroachdb#196, #42, #129, #98, 0x1, 0x1, 0, 0, ...)
server server.go:431 (*Server).Start(#5, cockroachdb#330, cockroachdb#196, #95, 0x1)
cli start.go:368 runStart(#34, #178, 0, 0x9, 0, 0)
cobra command.go:599 (*Command).execute(#34, #177, 0x9, 0x9, #34, #177)
cobra command.go:689 (*Command).ExecuteC(#33, #70, cockroachdb#343, #72)
cobra command.go:648 (*Command).Execute(#33, #71, cockroachdb#343)
cli cli.go:96 Run(#64, 0xa, 0xa, 0, 0)
main main.go:37 main()
We have been seeing long startup times which disappear spontaneously. During a
restart of the beta cluster, the following goroutine was observed, which suggests
that we were spending a lot of time GCing replicas on startup.
engine ??:0 _Cfunc_DBIterNext(cockroachdb#324, cockroachdb#323, 0, 0, 0, 0, 0, 0, 0)
engine rocksdb.go:1135 (*rocksDBIterator).Next(cockroachdb#235)
storage replica_data_iter.go:104 (*ReplicaDataIterator).Next(cockroachdb#316)
storage store.go:1748 (*Store).destroyReplicaData(#109, cockroachdb#317, 0, 0)
storage store.go:841 (*Store).Start.func2(0x101b, cockroachdb#300, 0x36, 0x40, cockroachdb#301, 0x36, 0x40, cockroachdb#315, 0x3, 0x4, ...)
storage store.go:734 IterateRangeDescriptors.func1(cockroachdb#306, 0x40, 0x41, cockroachdb#307, 0x92, 0x92, cockroachdb#341, 0, 0x186c, 0x4000, ...)
engine mvcc.go:1593 MVCCIterate(cockroachdb#329, #68, #47, #81, cockroachdb#232, 0x9, 0x10, cockroachdb#233, 0xb, 0x10, ...)
storage store.go:738 IterateRangeDescriptors(cockroachdb#330, cockroachdb#196, #47, #81, cockroachdb#195, #179, #110)
storage store.go:867 (*Store).Start(#109, cockroachdb#330, cockroachdb#196, #179, #185, 0x1)
server node.go:405 (*Node).initStores(#78, cockroachdb#330, cockroachdb#196, #98, 0x1, 0x1, #179, 0, #55)
server node.go:330 (*Node).start(#78, cockroachdb#330, cockroachdb#196, #42, #129, #98, 0x1, 0x1, 0, 0, ...)
server server.go:431 (*Server).Start(#5, cockroachdb#330, cockroachdb#196, #95, 0x1)
cli start.go:368 runStart(#34, #178, 0, 0x9, 0, 0)
cobra command.go:599 (*Command).execute(#34, #177, 0x9, 0x9, #34, #177)
cobra command.go:689 (*Command).ExecuteC(#33, #70, cockroachdb#343, #72)
cobra command.go:648 (*Command).Execute(#33, #71, cockroachdb#343)
cli cli.go:96 Run(#64, 0xa, 0xa, 0, 0)
main main.go:37 main()
Example functions for a simple Put & Get using Call(), and then for
Prepare() & Flush().
Each example is self-contained, and includes the server
setup/teardown. This makes the code closer to what would be used in
an actual client program.
The Prepare() & Flush() is a bit long because we have to create the values
we are later scanning for.