rk@tigase.net opened 2 weeks ago
-
Work Log
Design & Analysis (1.5–2.0 hours):
- Reviewed DSL core library contracts (ParsedQuery, SelectClause, WhereClause, Condition, OrderByClause) to define a stable execution boundary
- Identified mapping between DSL field names and Issue entity attributes
- Defined supported operator-to-predicate mappings for initial execution phase
- Explicitly scoped out query planning, optimization, and cross-entity joins
Execution Contract (0.5–1.0 hour):
- Defined execution flow: DSL string => ParsedQuery (parser) => ValidationResult (validator) => Specification => Repository execution => Projected query result
- Established error propagation rules from parser/validator to REST responses
- Defined generic QueryResult structure to decouple execution from UI concerns
Service Layer (2.0–3.0 hours):
- Implemented IssueQueryService as the central orchestration point
- Integrated DSL parser and validator into service pipeline
- Translated ParsedQuery WHERE clauses into JPA Specifications
- Implemented initial in-memory handling for ORDER BY and LIMIT (Phase 1)
- Implemented projection logic to extract selected fields from Issue entities
- Ensured service layer remains independent of REST and UI concerns
JPA Specification Integration (2.0–3.0 hours):
- Extended IssueSpecification with DSL-aware predicate builders
- Implemented predicate support for:
- Equality and inequality operators
- IN / NOT IN operators
- Range operators (BETWEEN)
- Temporal operators (OLDER_THAN, NEWER_THAN)
- Text operators (CONTAINS, STARTS_WITH, ENDS_WITH)
- Ensured compatibility with existing specification usage patterns
- Verified that DSL-driven specifications compose correctly with existing filters
REST Layer (1.5–2.5 hours):
- Implemented IssueQueryController for DSL execution
- Added endpoints for:
- parse + validate only (no execution)
- parse + validate + execute
- Integrated workflow availability checks using existing policy mechanism
- Disabled DSL execution endpoints by default via configuration
- Ensured consistent REST response structure for success and failure cases
Error Handling (0.5–1.0 hour):
- Mapped ParseException and validation errors to appropriate HTTP responses
- Ensured validation warnings are returned without blocking execution
- Verified that execution failures do not leak internal exceptions to clients
Testing (1.5–2.0 hours):
- Added unit tests for DSL-to-Specification translation
- Added service-level tests covering:
- valid query execution
- invalid DSL input
- unsupported operators or fields
- Verified correct interaction with IssueRepository
- Ensured tests avoid unnecessary Spring context bootstrapping
Documentation & Integration (0.5–1.0 hour):
- Documented execution flow and extension points for future optimization
- Verified backend execution is consumable by future UI and CLI layers
- Ensured no end-user UI exposure is introduced in this phase
Total Estimated Effort
Estimated: 8–12 hours
Outcome:
- Backend can execute validated DSL queries against Issue data
- Execution is correct, composable, and controlled
- System is prepared for subsequent UI and CLI integration without refactoring
-
rksuma@Ramakrishnans-MacBook-Pro sztab-query-dsl % git checkout wolnosc git pull Already on 'wolnosc' Your branch is up to date with 'origin/wolnosc'. Already up to date. rksuma@Ramakrishnans-MacBook-Pro sztab-query-dsl % git checkout -b feature/Issue-DSL-backend-execution Switched to a new branch 'feature/Issue-DSL-backend-execution' rksuma@Ramakrishnans-MacBook-Pro sztab-query-dsl % git push -u origin feature/Issue-DSL-backend-execution Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'feature/Issue-DSL-backend-execution' by visiting: remote: https://tigase.dev/sztab/~pulls/new?target=1325:wolnosc&source=1325:feature/Issue-DSL-backend-execution remote: To https://tigase.dev/sztab.git * [new branch] feature/Issue-DSL-backend-execution -> feature/Issue-DSL-backend-execution branch 'feature/Issue-DSL-backend-execution' set up to track 'origin/feature/Issue-DSL-backend-execution'. rksuma@Ramakrishnans-MacBook-Pro sztab-query-dsl % -
Previous Value Current Value Open
In Progress
-
Previous Value Current Value In Progress
Closed
| Type |
New Feature
|
| Priority |
Normal
|
| Assignee | |
| Version |
none
|
| Sprints |
n/a
|
| Customer |
n/a
|
Issue Votes (0)
Watchers (3)
Description
This issue implements the backend execution layer for the Issue Query DSL, building on top of the standalone DSL core library.
The goal of this phase is to make parsed and validated DSL queries executable against the existing Issue persistence model, without introducing any end-user UI exposure yet. The backend will translate DSL constructs into JPA Specifications, orchestrate query execution, and expose controlled REST endpoints gated by availability policy.
This phase focuses on correctness, composability, and controlled exposure. Performance optimizations and query planning are explicitly deferred.
Scope
Included:
Explicitly Excluded:
Architecture Notes
Time Estimate
Estimated: 8–12 hours
Work Log (Planned)
Design:
Service Layer:
JPA Integration:
REST Layer:
Testing:
Status
Planned
This issue establishes backend execution for the Issue Query DSL and prepares the system for controlled exposure to UI and CLI consumers in subsequent phases.