1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
|
/**
* @mainpage Relational NT
*
* @image html logo.png
*
* Relational NT is an experimental database kernel inspired by the
* object-management model of the Windows NT kernel. The project applies the
* same style of explicit object management to database state: relations,
* tuples, transactions, namespaces, permissions, cursors, and handles are
* treated as runtime-managed objects rather than isolated subsystems.
*
* The current codebase is intentionally early-stage. Most classes define the
* boundaries of the runtime and document the design constraints that should
* guide future implementation.
*
* @section architecture Architecture Direction
*
* - ObjectManager registers, locates, and references database objects.
* - PermissionsManager keeps security checks separate from object lookup.
* - IdentityManager decides whether an object supports lifecycle operations
* such as open and close.
* - LifecycleManager models monitoring, pinning, cleanup, and contention.
* - HandlerManager represents authorized access through explicit handles.
* - CursorManager bridges durable snapshots and pull-based query execution.
* - VM separates terminating relational retrieval from higher-order logic
* execution.
*
* @section design Design Notes
*
* The following documents record architectural decisions and comparisons with
* the ReactOS NT kernel, which this project draws from:
*
* - **docs/reactos-ob-comparison.md** — Object manager comparison: dual
* reference counting, type callbacks, hash directory, per-handle access
* masks, capability security, branch HEAD contention, and the namespace
* reparse layer.
*
* - **docs/nt-architecture-mapping.md** — Holistic mapping of the full NT
* kernel to a database kernel: wire protocols as environment subsystems,
* the I/O driver stack as the query operator pipeline, drivers as storage
* backends, MM as the buffer pool, CC as the WAL flusher, PS as the
* session manager, SE as the authorization engine, and LPC as the wire
* protocol connection layer.
*
* @section building Building
*
* From a Visual Studio/NMake environment:
*
* @code{.sh}
* nmake /f Makefile windows
* @endcode
*
* From a Unix-like environment with Make and a C++17 compiler:
*
* @code{.sh}
* make unix
* @endcode
*
* @section docs Generating Documentation
*
* Install Doxygen and run:
*
* @code{.sh}
* doxygen Doxyfile
* @endcode
*
* The generated HTML documentation is written to docs/generated/html.
*/
/**
* @namespace nt
* @brief Contains the Relational NT runtime managers and API facade.
*/
|
