record_bridge.hpp File Reference

The record bridge: ErasedRecordSink / ErasedRecordSource implement the non-templated RecordSink / RecordSource (codec.hpp) over a std::vector<Record> — with the field-access machinery compiled ONCE (record_bridge.cpp), not once per record type. More...

#include <array>
#include <cstddef>
#include <cstdint>
#include <span>
#include <string>
#include <string_view>
#include <type_traits>
#include <vector>
#include <meta>
#include <wowlib/db/codec.hpp>
#include <wowlib/db/schema.hpp>

Include dependency graph for record_bridge.hpp:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Classes
struct	wowlib::db::detail::ColumnAccess
	Everything the erased core needs to touch one column of a record: where it lives, what it is, and how its array elements stride. More...
struct	wowlib::db::detail::RecordOps
	The one thing that stays per-record: a table of thunks over the record VECTOR (only they know sizeof(Record)) plus the access table above. More...
class	wowlib::db::ErasedRecordSink
	RecordSink over a live std::vector<Record>& — the decode target. More...
class	wowlib::db::ErasedRecordSource
	RecordSource over a const std::vector<Record>& — the encode source. More...

Namespaces
namespace	wowlib
namespace	wowlib::db
namespace	wowlib::db::detail

Enumerations
enum class	wowlib::db::detail::AccessKind : std::uint8_t {   wowlib::db::detail::I8 , wowlib::db::detail::U8 , wowlib::db::detail::I16 , wowlib::db::detail::U16 ,   wowlib::db::detail::I32 , wowlib::db::detail::U32 , wowlib::db::detail::I64 , wowlib::db::detail::U64 ,   wowlib::db::detail::F32 , wowlib::db::detail::Str , wowlib::db::detail::LocStr }
	The storage kind of one record member, as the erased accessors see it: exact width and signedness for integers (the store must truncate the codec's int64 exactly as the typed member assignment did), float, std::string, or LocString. More...

Functions
template<typename E>
consteval AccessKind	wowlib::db::detail::accessKindOf ()
	The AccessKind of element type E (consteval; bool is rejected by classifyMember long before this runs).
template<typename Struct>
consteval std::uint32_t	wowlib::db::detail::memberOffset (std::string_view name)
	The byte offset of Struct's member named name (consteval).
template<typename Record>
consteval auto	wowlib::db::detail::columnAccessOf ()
	The per-column access table of Record: one ColumnAccess per member, declaration order — the same 1:1 correspondence schemaOf() rests on.
template<typename Record>
consteval std::size_t	wowlib::db::detail::idColumnOf ()
	The $id$ column index of Record (consteval), or SIZE_MAX.

Variables
template<typename Record>
constexpr RecordOps	wowlib::db::detail::RecordOpsFor
	The RecordOps instance of Record — the entire per-record residue.

Detailed Description

The record bridge: ErasedRecordSink / ErasedRecordSource implement the non-templated RecordSink / RecordSource (codec.hpp) over a std::vector<Record> — with the field-access machinery compiled ONCE (record_bridge.cpp), not once per record type.

The previous bridge (TypedRecordSink<Record>) reflection-expanded a member-dispatch chain per record type: six virtual methods times a template for over every member, times ~4200 bound (table x era) records. Measured on the Python bindings, that was ~128 KB of near-identical object code per binding shard — yet everything those chains did was fully determined by three facts per column: the member's byte OFFSET, its value KIND, and its element STRIDE. Those are data, not code. So the bridge now derives a static ColumnAccess table per record (consteval, from the same reflection schemaOf() uses) and hands it to a shared non-templated core; what remains per record is that table plus a handful of one-line vector thunks (clear/reserve/add/at/clone) nothing can erase, because only they know sizeof(Record).

Nothing about the public API changes: Table<Record> constructs the erased bridge from its records vector exactly as it constructed the typed one.

Definition in file record_bridge.hpp.