vasily/TCPDashboard
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

4.0 - 3.0 Implement strategy analysis tables and repository for backtesting

Browse Source 
- Added `StrategyRun` and `StrategySignal` models to track strategy execution sessions and generated signals, respectively, ensuring a clear separation from live trading data.
- Introduced `StrategyRepository` for managing database operations related to strategy runs and signals, including methods for creating, updating, and retrieving strategy data.
- Updated `DatabaseOperations` to integrate the new repository, enhancing the overall architecture and maintaining consistency with existing database access patterns.
- Enhanced documentation to reflect the new database schema and repository functionalities, ensuring clarity for future development and usage.

These changes establish a robust foundation for strategy analysis and backtesting, aligning with project goals for modularity, performance, and maintainability.
This commit is contained in:
Vasily.onl
2025-06-12 15:29:14 +08:00
parent d34da789ec
commit f09864d61b
7 changed files with 529 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
tasks/4.0-strategy-engine-foundation.md
View File

@@ -63,6 +63,16 @@
- **Reasoning**: Ensures consistency with the `BaseStrategy` abstract class, which now requires `strategy_name` during initialization, providing a clear identifier for each strategy instance.
- **Impact**: All strategy implementations now correctly initialize their `strategy_name` via the base class, standardizing strategy identification across the engine.
### 5. Database Schema Design for Strategy Analysis
- **Decision**: Created separate `strategy_signals` and `strategy_runs` tables distinct from the existing `signals` table used for bot operations.
- **Reasoning**: Maintains clear separation between live bot trading signals and strategy analysis/backtesting data, avoiding conflicts and ensuring data integrity for different use cases.
- **Impact**: Strategy analysis can be performed independently without affecting live trading operations, with dedicated tables optimized for analytical queries and data retention policies.
### 6. Repository Pattern Integration
- **Decision**: Implemented `StrategyRepository` following the established `BaseRepository` pattern and integrated it into the centralized `DatabaseOperations` class.
- **Reasoning**: Maintains consistency with existing database access patterns, ensures proper session management, and provides a clean API for strategy data operations.
- **Impact**: All strategy database operations follow the same patterns as other modules, with proper error handling, logging, and transaction management.
## Tasks
- [x] 1.0 Core Strategy Foundation Setup
@@ -88,16 +98,16 @@
- [x] 2.8 Implement strategy parameter validation and default value handling
- [x] 2.9 Add configuration export/import functionality for strategy sharing
- [ ] 3.0 Database Schema and Repository Layer
- [ ] 3.1 Create new `strategy_signals` table migration (separate from existing `signals` table for bot operations)
- [ ] 3.2 Design `strategy_signals` table with fields: strategy_name, strategy_config, symbol, timeframe, timestamp, signal_type, price, confidence, metadata, run_id
- [ ] 3.3 Create `strategy_runs` table to track strategy execution sessions for backtesting and analysis
- [ ] 3.4 Implement `StrategyRepository` class in `database/repositories/strategy_repository.py` following repository pattern
- [ ] 3.5 Add strategy repository methods for signal storage, retrieval, and batch operations
- [ ] 3.6 Update `database/operations.py` to include strategy operations access
- [ ] 3.7 Create database indexes for optimal strategy signal queries (strategy_name, symbol, timeframe, timestamp)
- [ ] 3.8 Add data retention policies for strategy signals (configurable cleanup of old analysis data)
- [ ] 3.9 Implement strategy signal aggregation queries for performance analysis
- [x] 3.0 Database Schema and Repository Layer
- [x] 3.1 Create new `strategy_signals` table migration (separate from existing `signals` table for bot operations)
- [x] 3.2 Design `strategy_signals` table with fields: strategy_name, strategy_config, symbol, timeframe, timestamp, signal_type, price, confidence, signal_metadata, run_id
- [x] 3.3 Create `strategy_runs` table to track strategy execution sessions for backtesting and analysis
- [x] 3.4 Implement `StrategyRepository` class in `database/repositories/strategy_repository.py` following repository pattern
- [x] 3.5 Add strategy repository methods for signal storage, retrieval, and batch operations
- [x] 3.6 Update `database/operations.py` to include strategy operations access
- [x] 3.7 Create database indexes for optimal strategy signal queries (strategy_name, symbol, timeframe, timestamp)
- [x] 3.8 Add data retention policies for strategy signals (configurable cleanup of old analysis data)
- [x] 3.9 Implement strategy signal aggregation queries for performance analysis
- [ ] 4.0 Strategy Data Integration
- [ ] 4.1 Create `StrategyDataIntegrator` class in new `strategies/data_integration.py` module