mt-update-ttl : use standard store, specify TTL's not tables, auto-create tables + misc #1173
Conversation
notes: * cassandra-concurrency now sets the WriteConcurrency setting, to end up at the same behavior of setting .NumConns * new flags: window-factor, create-keyspace, schema-file
Dieterbe
force-pushed
the
mt-update-ttl-updates
branch
from
90a28cf
to
ea785e5
Compare
cmd/mt-update-ttl/main.go
Outdated
| flag.Usage = func() { | ||
| fmt.Fprintln(os.Stderr, "mt-update-ttl [flags] ttl table-in [table-out]") | ||
| fmt.Fprintln(os.Stderr) | ||
| fmt.Fprintln(os.Stderr, "Adjusts the data in Cassandra to use a new TTL value. The TTL is applied counting from the timestamp of the data") | ||
| fmt.Fprintln(os.Stderr, "If table-out not specified or same as table-in, will update in place. Otherwise will not touch input table and store results in table-out") | ||
| fmt.Fprintln(os.Stderr, "In that case, it is up to you to assure table-out exists before running this tool") | ||
| fmt.Fprintln(os.Stderr, "Unless you disable create-keyspace, table-out is created when necessary") |
There was a problem hiding this comment.
This assumes that table-out is named using the internal naming convention of MT. But there are no checks to ensure that is true.
There was a problem hiding this comment.
i suppose we could check if the table generated for the requested TTL matches the name specified.
but at that point, we may as well get rid of the table-out argument and just always generate it automatically. mt-update-ttl then knows the right destination table without further user input, and even know when to do updates (if it's same as table-in) or copies (if it's different). does that sound good to you @woodsaj ?
There was a problem hiding this comment.
That seems reasonable, but you should then do the same for both the input and out tables. ie old-ttl, new-ttl
Dieterbe
force-pushed
the
mt-update-ttl-updates
branch
from
cb02c1b
to
5f52ccb
Compare
Dieterbe
changed the title
|
@woodsaj PTAL |
No description provided.