[Carbonic-Acidd]

Overview

Connects GET /api/races and GET /api/races/{id}/laps/{lap}/positions to OrionDB, replacing hardcoded stubs with live queries to races and estimated_positions.

• Database Connection: Added shared DB connection setup (orion/connection.py) and table schemas (orion/schema.py).
• Backend Refactor: Replaced stub methods with real queries across the controller, service, and repository layers.
• Error Handling: Added validation returning 422 for bad inputs, 404 for missing races, and 500/503 for DB errors.
• Cleanup: Marked remaining stubs with # STUB

Technical Description

Added a FastAPI database dependency backed by a shared SQLAlchemy engine and injected connections into the wired route handlers. The race repository now queries the races table, while the positions repository queries estimated_positions by race and lap, with optional latitude/longitude bounds and timestamp ordering.

The service layer checks that a requested race exists before querying positions, allowing a valid race with no position data to return [] while an invalid race returns 404. Database-specific exceptions are converted into OrionDB errors and then into clean HTTP responses by FastAPI.

How Has This Been Tested?

Automated and Live Tests that cover

• Database connection
• /api/health/db connectivity and database configuration failures
• Ensuring the front end and backend doing GET /api/races return [] for an empty database
• 404 responses for unknown race IDs
• Race and position response shapes matching the existing frontend stubs
• Database connection and schema failures returning clear 500/503 responses
• Remaining stub endpoints continuing to return valid responses

Ticket Review

Answer the following:

1. What went well

• The layered architecture (controller -> services -> repository) made implementing the Connection easy.

2. What was difficult

• Because the ORION DB lacks any data, live verification was limited to empty state paths.

3. If you could start over what would you do differently

• I would've spent more time initially planning everything out instead of trying to build each part at once, leading to a lot of back and forth.

[shreya-m9]

Looks good to me!

[shreya-m9]

Looks good to me!

[TKDPenguin]

Looks good to me. Just make sure you handle the merge conflict before you merge