|
Lightweight 0.20260625.0
|
One column pair of a composite foreign key: "this record's column references that one". More...
#include <CompositeForeignKey.hpp>
Public Types | |
| using | FromRecord = MemberClassType< decltype(FromPtr)> |
| The record this connection starts from. | |
| using | IntoRecord = MemberClassType< decltype(IntoPtr)> |
| The record this connection points at. | |
| using | FromField = std::remove_cvref_t< typename detail::MemberPointeeType< decltype(FromPtr)>::type > |
| using | IntoField = std::remove_cvref_t< typename detail::MemberPointeeType< decltype(IntoPtr)>::type > |
| The field type on the referenced record's side. | |
Static Public Member Functions | |
| template<typename RecordT = FromRecord> | |
| static auto const & | FieldOf (RecordT const &record) noexcept |
| static consteval std::size_t | FromMemberIndex () noexcept |
Static Public Attributes | |
| static constexpr auto | From = FromPtr |
| Pointer to this record's foreign key member. | |
| static constexpr auto | Into = IntoPtr |
| Pointer to the referenced record's primary key member. | |
| static constexpr std::size_t | IntoMemberIndex = MemberIndexOf<IntoPtr> |
One column pair of a composite foreign key: "this record's column references that one".
Both endpoints are pointers-to-member, so the pairing is part of the type. That is the whole point: with two parallel column lists the pairing would be implicit in position, and transposing two same-typed columns would be silently wrong. Here a transposition is a different Connection, and where the paired columns differ in type it does not even compile.
| FromPtr | Pointer to the member of this record holding part of the foreign key. |
| IntoPtr | Pointer to the member of the referenced record it points at, which must be a primary key there. |
Definition at line 56 of file CompositeForeignKey.hpp.
| using Lightweight::Connection< FromPtr, IntoPtr >::FromRecord = MemberClassType<decltype(FromPtr)> |
The record this connection starts from.
Definition at line 72 of file CompositeForeignKey.hpp.
| using Lightweight::Connection< FromPtr, IntoPtr >::IntoRecord = MemberClassType<decltype(IntoPtr)> |
The record this connection points at.
Definition at line 75 of file CompositeForeignKey.hpp.
| using Lightweight::Connection< FromPtr, IntoPtr >::FromField = std::remove_cvref_t<typename detail::MemberPointeeType<decltype(FromPtr)>::type> |
The field type on this record's side, e.g. Field<int32_t>.
Taken from the pointer-to-member's own type rather than from a declval of the owning record: the declaring record is incomplete while this relation is instantiated as one of its members.
Definition at line 89 of file CompositeForeignKey.hpp.
| using Lightweight::Connection< FromPtr, IntoPtr >::IntoField = std::remove_cvref_t<typename detail::MemberPointeeType<decltype(IntoPtr)>::type> |
The field type on the referenced record's side.
Definition at line 92 of file CompositeForeignKey.hpp.
|
inlinestaticnoexcept |
Reads this connection's field out of record.
Wraps the member access so the two reflection modes differ in exactly one place: the non-reflection branch uses a pointer-to-member, while the C++26 branch splices the reflection.
| record | The record holding the foreign key. |
Definition at line 103 of file CompositeForeignKey.hpp.
|
inlinestaticnoexcept |
Member index of this record's foreign key member within its own record.
A function rather than a variable: the declaring record is still incomplete while this relation is instantiated as one of its members, so reflecting over it has to wait until first use.
Definition at line 116 of file CompositeForeignKey.hpp.
|
staticconstexpr |
Pointer to this record's foreign key member.
Definition at line 59 of file CompositeForeignKey.hpp.
|
staticconstexpr |
Pointer to the referenced record's primary key member.
Definition at line 62 of file CompositeForeignKey.hpp.
|
staticconstexpr |
Member index of the referenced member within the referenced record.
This is what makes the relation independent of the order its connections are written in: the WHERE clause of a primary key lookup is emitted in the referenced record's member declaration order, so values must be permuted into that order before being bound. See CompositeForeignKey::OrderedValuesOf.
Definition at line 127 of file CompositeForeignKey.hpp.