Context:
Signals are the core content of StellarSwipe. Each signal represents a trade recommendation with asset pairs, action (buy/sell), rationale, and performance tracking.
Problem:
Create a comprehensive database schema that captures all signal attributes while supporting efficient querying for the feed and analytics.
What Done Looks Like:
- Signal entity with all required fields
- Relationships to users (providers), assets, and trades
- Indexing for feed queries
- Support for signal versioning/updates
- Performance tracking fields
Folder Structure:
src/
├── signals/
│ ├── entities/
│ │ ├── signal.entity.ts
│ │ ├── signal-performance.entity.ts
│ │ └── signal-interaction.entity.ts
│ ├── dto/
│ ├── signals.service.ts
│ ├── signals.controller.ts
│ └── signals.module.ts
Required Fields:
- id, provider_id, asset_pair, action (BUY/SELL)
- entry_price, target_price, stop_loss
- rationale (text), confidence_score (0-100)
- status (ACTIVE, EXPIRED, CLOSED)
- created_at, expires_at, executed_count
- total_profit_loss, success_rate
Implementation Guidelines:
- Use enum for signal status and action types
- Add composite index on (status, created_at) for feed queries
- Include soft delete for compliance
- Add validation decorators for price fields
- Foreign key to users table for provider
Edge Cases:
- Signal expiration handling
- Price validation (target > entry for BUY)
- Duplicate signal detection
Validation:
- Create signal with all fields
- Query signals by status
- Update performance metrics
- Soft delete works correctly
Context:
Signals are the core content of StellarSwipe. Each signal represents a trade recommendation with asset pairs, action (buy/sell), rationale, and performance tracking.
Problem:
Create a comprehensive database schema that captures all signal attributes while supporting efficient querying for the feed and analytics.
What Done Looks Like:
Folder Structure:
Required Fields:
Implementation Guidelines:
Edge Cases:
Validation: