By using free functions that take the serializer as a parameter (rather than
'this'), we can add serialization functions without changing the serializer
class.
rpc currently allows serializers and deserializers to defer, because
the input and output stream may not be ready. They may not, however,
defer on behalf of the object being serialized or deserialized (i.e.
you cannot serialize to disk or deserialize from disk) because that
causes the tcp connection to block until serialization/deserialization is
complete. So in practice messages must be small enough to fit in memory,
and there is nothing gained by the complexity.
To simplify things, switch to non-deferring serialization. Add a frame
header to messages that specifies the buffer size, which allows rpc to
use a read_exacly() to consume the message, and thereafter deserialize it
immediately.
The result is significantly simpler, which should help with compile time.
config.hh changes rapidly, so don't force lots of recompiles by including it.
Need to place seed_provider_type in namespace scope, so we can forward
declare it for that.
It should not be called directly: externall callers should be calling flush()
instead.
To be sure it doesn't happen again, make seal_active_memtable private.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
When we create a column family, we can pass as an extra parameter, the
commitlog - or lack thereof. Because the commitlog is optional to begin with -
it won't exist if we don't call init_commitlog, we can have this to be empty
meaning no commit log.
The creation of a column family should be always done through
add_column_family. And if that is the case, we have the database's commitlog
right there and can get the pointer through the db. Only tests are not creating
the column family this way, and for them, it is fine.
We want to do that, because some column family operations will use the commit log.
Right now, they are forcing us to add parameters to APIs that would be much cleaner
without it. So while separation is good, this level of coupling is a net win as it
allows us to clean up some visible APIs.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
"Fixes for ORDER BY clauses" from Pawel.
"The patches fix several issues in CQL3 frontend related to ORDER BY
clauses. Also, column component indexes are now handled properly and it
is possible to create tables with more than one column in clustering key."
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.
We don't really handle expiration of entrie rows yet, due to issue #17.
Fixing a bug in 'insert' made this test start to fail because the
expired row started to appear in the results. Until #17 is fixed,
let's use 'update' to create the row, so that the expectations are
met.
"(Partial?) implementation of BatchLogManager.
Requires the token function/restriction series.
Functional as in that it can create batchlog mutations, and do replay
of data in this system table.
Since range queries does not yet work, it only handles a very small
table contents.
It is not used yet either, but will eventually be needed for batch statements
etc."
The messaging service is initialized very early, before we have the
proxy or query processor initialized. It is mostly fine, except for
the fact that the messaging service also finishes the initialization
of the storage service. That part will issue queries agains the system
tables, (as soon as we support them), and need to happen later.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
