In much of our column_families APIs, we need to pass a pointer to the database.
The only reason we do that, is so we can properly handle the commit log entries
after we seal the current memtables into sstables.
Now that we store a pointer to the commit log in the CF itself at the time it
is created, we no longer have to do it. As a result, the APIs are a lot
cleaner, with no gratuitous parameters.
My motivation for this was the flush method, but as a result, apply() also gets
cleaner.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
The logger class constructor registers itself with the logger registry,
in order to enable dynamically setting log levels. However, since
thread_local variables may be (and are) initialized at the time of first
use, when the program starts up no loggers are registered.
Fix by making loggers global, not thread_local. This requires that the
registry use locking to prevent registration happening on different threads
from corrupting the registry.
Note that technically global variables can also be initialized at the
point of first use, and there is no portable way for classes to self-register.
However this is the best we can do.
"Some of the system tables will set gc_grace_seconds, or default_time_to_live
but right now we are commenting them out.
The best way to do it would have been to somehow save the fields so we don't need to
set it all the time - as this function is effectively doing.
However, those fields would feel very spurious in the constructor, and it is not
like there isn't a lot of other things for us to set. More importantly, calling
those schema functions is a very rare event. We usually call it once and store
the pointer somewhere.
With that, we're very close to implementing everything that the system tables
needs set, missing only COMPACT STORAGE and information about compaction
strategy."
The function is currently just a simple wrapper over
storage_proxy::query(). The comment has description of details which
are much lower level than this interface.
All CFMetaData has a type, either Standard or Super. Right now, we do not
support Super, but we still would like to query for it, and use that information
to build our schemas.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
There are two versions of update_tokens: one for the tokens used by this node,
which goes to the local table, and another for the remote tokens, used by
remote nodes, which goes to the peers table.
The former was implemented, the latter was not. Implement it.
One node: Origin does not issue a flush here, at least in the version of the
code we imported. However, a flush is present in all other variants, and won't
hurt, aside from creating an extra, probably very small, sstable. So I'm
flushing.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
We ended up with two different implementations of force_blocking_flush,
none of them ideal.
This patch merges both in one that makes more sense, getting rid of the
duplication.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
To implement that, we will resort to a cache mechanism, instead of doing the
query all the time. This is mainly because we want to avoid overfuturization
of the callers, that are usually just interested in passing simple strings
around.
We will be able to intercept all updates to it, and maintain consistency with our
internal cache. The updates are not done in this patchset.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
This function is called at bootstrap, to make sure the system tables exist in
the keyspace list. I honestly don't know why do we have to force a delete +
reconstruct. But let's keep consistency with Origin here.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
"As previously said, there were some unidentified bugs that prevented update_tokens from
working properly. The first one was sent alongside the series, the second one took me more
time, but it is fixed here."
Somewhat simplifies version of the Origin code, since from what I
can see, there is less need for us to do explicit query sends in
the BLM itself, instead we can just go through storage_proxy.
I could be wrong though.
At this point, users of the interface are futurized already, so we
just need to make sure they call the right function.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
This function is called at startup and makes sure that the cluster_name field
in system.local exists, and if it exists, that it matches the expected value.
To simplifly things, I am leaving the sstable check out. For us, that would be
a map-reduce operation, and if the sstables are indeed corrupted, we would have
caught that already for sure.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
This patch provide a function to store the current schema version.
Currently, it is called every time the node boots, with a random schema.
That is incorrect and will be fixed shortly. But for now, cqlsh needs
to see a valid value here, so this will do.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
We will have to flush it from other places as well, so wrap the flushing code
into a method - specially because the current code has issues and it will be
easier to deal with it if it is in a single place.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
We won't create our own versions of database and query_proxy, so we need
some setup to be done. The current code will capture those variables and
setup the structure used to conduct the queries. Later on, it will also
carry on the database's basic setup.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
We always operate on the local storage proxy so pass it by reference.
This simplifies DEFINITIONS_UPDATE message handler where all we have is
a "this" pointer to the local storage proxy.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Persist column family's "is_dense" value to system tables. Please note
that we throw an exception if "is_dense" is null upon read. That needs
to be fixed later by inferring the value from other information like
Origin does.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Enable column family "bloom_filter_fp_chance" from the CQL front-end and
make sure its persisted to system tables.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
