forked from animatedread/Warrior_EA
74c7395127
- Define MAX_WEIGHT constant (1.0e6) for weight limits in clusters - Remove redundant barrier from FeedForward kernel (prevents sync issues) - Port FeedForwardProof and CalcInputGradientProof kernels for max-pooling (no weights, sliding max) - Port FeedForwardConv kernel for convolution layers (shared weights, multiple output channels) - Remove unused code and refactor signal condition logic (CSignalPAI)
55 lines
3.1 KiB
Markdown
55 lines
3.1 KiB
Markdown
# Database Module Documentation
|
|
|
|
## Overview
|
|
The Database module in Warrior_EA provides robust, fault-tolerant management of all persistent data required by the EA, including signal statistics, ranking, and versioning. It is designed for reliability, modularity, and ease of integration with the AI/ML and signal subsystems.
|
|
|
|
---
|
|
|
|
## Key Components
|
|
|
|
### 1. DatabaseManager.mqh
|
|
- **CDatabaseManager**: Orchestrates all database operations, including initialization, version management, file system operations, and transactional safety. Integrates:
|
|
- CDatabaseConnectionManager: Handles opening/closing database connections and transaction state.
|
|
- CDatabaseVersionManager: Manages versioning and upgrades of the database schema/files.
|
|
- CDatabaseFileSystemManager: Handles directory and file operations with retry logic.
|
|
- CDatabaseOperationsManager: Executes SQL queries and manages prepared statements.
|
|
- **Design Notes**: Implements retry logic, version checks, and safe upgrades. Cleans or recreates directories as needed for version mismatches or training mode.
|
|
|
|
### 2. DatabaseConnectionManager.mqh
|
|
- **CDatabaseConnectionManager**: Manages the lifecycle of a database connection, including retries, transaction begin/commit/rollback, and verbose logging. Ensures only one open handle at a time and provides robust error handling.
|
|
|
|
### 3. DatabaseFileSystemManager.mqh
|
|
- **CDatabaseFileSystemManager**: Provides safe, retry-based wrappers for directory creation, cleaning, and file deletion. Ensures file system operations are robust against transient errors.
|
|
|
|
### 4. DatabaseOperationsManager.mqh
|
|
- **CDatabaseOperationsManager**: Higher-level manager for executing and retrying SQL queries, creating tables, and managing prepared statements. Integrates with the connection manager for handle management.
|
|
|
|
### 5. DatabaseVersionManager.mqh
|
|
- **CDatabaseVersionManager**: Handles reading and updating the database version file, with retry logic for file I/O. Ensures schema upgrades and version mismatches are handled safely.
|
|
|
|
---
|
|
|
|
## Design Highlights
|
|
- **Fault Tolerance**: All file and database operations use retry loops and error logging to maximize reliability.
|
|
- **Transactional Safety**: Explicit transaction management with rollback on failure.
|
|
- **Versioning**: Database version is tracked and enforced, with automatic upgrades and directory cleaning as needed.
|
|
- **Separation of Concerns**: Each class has a clear, single responsibility, following SOLID principles.
|
|
- **Integration**: Designed to work seamlessly with the AI/ML and signal modules for persistent storage of model weights, statistics, and rankings.
|
|
|
|
---
|
|
|
|
## Usage Patterns
|
|
- Initialize the database via `CDatabaseManager.Init()` with version and directory structure.
|
|
- Use connection and operations managers for all SQL and file operations.
|
|
- Always check return values for error handling and retries.
|
|
|
|
---
|
|
|
|
## Next Steps
|
|
- Add unit tests for all database operations and error paths.
|
|
- Expand documentation for each SQL schema/table used.
|
|
- Continue with documentation of Enumerations/ next.
|
|
|
|
---
|
|
|
|
*This documentation will be updated as additional files are analyzed and integrated.*
|