GitLab

The sqlite3 code needed to be fixed up due to the new signature for
`lattutil_log_init`.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

This ensures that log messages are printed on the screen in proper
order.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Even the function declarations were gated behind _lattutil_internal, the
functions can be declared static in their respective files.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

The name of the table is passed in to the logger's init function.

The SQLite3 logger will create the following table if it doesn't already
exist:

CREATE TABLE IF NOT EXISTS <table> (
	timesec BIGINT NOT NULL,
	timeusec BIGINT NOT NULL,
	msgtype TEXT NOT NULL,
	msg TEXT NOT NULL
)

Of course, replace `<table>` with the name of the table.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

No current plans to use `lsq_flags` in `lattutil_sqlite_query_t`, but
create the struct member in case we need it in the future.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

If the consuming code doesn't pass in a logger, make life easy for the
library code by instantiating a logging object, leaving it in dummy
mode.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

We'll want to eventually log any parameters, which will make this
complex enough to warrant its own function.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

While here, also start the work for logging queries.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>
issue:		#2

We may want to store additional arbitrary data, specific to the
underlying implementation.

For example, when I implement libpushover-based logging, I'll want to
store a libpushover context object in the logger context. I don't want
that exposed to the application, though.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Applications that consumes these objects may want to attach arbitrary
data to them. The liblattutil library will never make use of these
members.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Only info goes to stdout, all the rest go to stderr.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Versioning the objects makes it easy to know ABI compat between old
version of the library and new.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

This just gets the rows and columns by IDs. A follow-up commit will
provide a name-based column accessor.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

This commit provides a unified API for performing SQLite3 queries.
Queries that return rows store their resulting data in a libucl object
tree.

Using libucl enables us to do some pretty powerful things, like convert
a SQLite3 database to JSON as one example. We can construct complex
object trees, clone objects, etc.

Not all data types are supported--only the ones I myself need right this
very moment. A more complete data type support will follow later as the
need arises.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

The dummy log is the default and is effectively a NOP. It's set in case
the user forgets to use a real logging backend (syslog is the only other
supported logging backend right now).
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Also prepend the message with the type of message (ERROR, INFO,
WARNING).
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>

Only syslog is supported at this time.
Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org>