log_service_imp.h File Reference

#include <mysql/components/services/log_service.h>
#include <mysql/components/services/log_shared.h>

Go to the source code of this file.

Classes
class	log_service_imp

Functions
	REQUIRES_SERVICE_PLACEHOLDER (registry)
	LOG SINKS: WRITERS. More...

Function Documentation

REQUIRES_SERVICE_PLACEHOLDER()

REQUIRES_SERVICE_PLACEHOLDER

(

registry

)

LOG SINKS: WRITERS.

There are two types of writers. "Modern services" like the XML or JSON writers don't care whether a key/value pair is a table name or an error message, or what – a string is a string. Thus, these services have to cover just three cases: format as string, format as integer, or format as float. Trivial.

The other type is services that write to a fixed format, like the traditional MySQL error log. The error log has a timestamp, connection ID, severity label, and an error message, in that exact order. The traditional error log service therefore doesn't attempt to process all the information we might send its way; it just needs to know how to retrieve the few items it's interested in, and about printing them in the prescribed order. All other information is ignored. Still simple, just a different kind of simple.

INPUT

So as we've seen, both kinds of writers are quite straightforward. It's either "handle 3 storage classes" (which is simple) or "handle as many specific item types are you're interested in". The first group (which handles any and all items) is actually the simplest, and perhaps easier to read and understand than the second group, as they're little more than a glorified

switch (item->item_class) { case STRING: sprintf(buf, "%s", item->value.data_string); break; case INTEGER: sprintf(buf, "%d", item->value.data_integer); break; case FLOAT: sprintf(buf, "%f", item->value.data_float); break; }

Anything beyond that in a given source file is usually either boilerplate code needed by the component framework (which is going to be there no matter how simple or complex our actual writer is) or required by the specific output format the sink is intended to generate (writing e.g. JSON rows or XML tags, escaping characters/entities in string values, indentation, and so on).

ERROR MESSAGES THAT AREN'T STRINGS, AND OTHER INSANITY

So what if a service is looking for the error message, but it turns out that message is not a string?

Well, first off, the well-know items (log message, error number, ...) all also have a well-known storage class, so an error message for example shall always be of string class. Our code (submission API, filter, ...) ensures this. Additionally, there is code in the server to help guard against broken modules that violate these guarantees, so individual loadable services won't have to check that themselves, either.

In summary, if a case like that happens, it's a bug, and it's a bug that we have tools to detect. The expectation is NOT that services have to convert data-types on the fly and be able to handle error messages that are numbers, or integers that come wrapped in a string, or any such nonsense. It is true that modern writers like XML or JSON gracefully handle this case at zero overhead (as they only look at storage class, not type or semantics), but this is very specifically NOT required of any service.