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.
Add a parse_type() function for parsing a serialized type name and
returning a data_type for it. Please note that collection types are
handled elsewhere.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
We must compare types with ->equal(). Fixes keyspace merging issues
where the merging code mistakenly thinks two keyspaces are different and
calls the alter keyspace path which is not implemented.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Tomek says:
"Some types may yield different byte-representations for equal
values."
Fix that up.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Convert code to use the deserialize() function and drop the duplicate
compose() wrapper that we inherited from Origin.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Add a data_value class that also encodes a value type. This makes it
easier to use than plain boost::any for comparing two values.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
bytes and sstring are distinct types, since their internal buffers are of
different length, but bytes_view is an alias of sstring_view, which makes
it possible of objects of different types to leak across the abstraction
boundary.
Fix this by making bytes a basic_sstring<int8_t, ...> instead of using char.
int8_t is a 'signed char', which is a distinct type from char, so now
bytes_view is a distinct type from sstring_view.
uint8_t would have been an even better choice, but that diverges from Origin
and would have required an audit.
At present, no overloads are needed because collections are interned, and
all other implemented data types are singletons. Tuples and user defined
types will need an overload.
Instead of using inefficient std::ostream, use our own 'bytes' iterator class.
Compute ahead of time the length of the byte buffer.
Afterwards serialize the objects into it.
Gives ~X5 boost over previus results (that sometimes don't even
finish in reasonable time)
[avi: add missing include]
