rk@tigase.net opened 2 weeks ago
-
Time Estimate
Area Estimated Time DSL grammar, AST model 6–8 hours Lexer, parser, validator 6–8 hours JPA Specification mapping 6–8 hours Service layer execution logic 4–6 hours REST controller & DTOs 2–3 hours Web UI (DSL editor + results) 6–8 hours CLI (Spring Shell integration) 3–4 hours Query templates & examples 1–2 hours Error handling & edge cases 3–4 hours Demo preparation (UI + CLI) 2–3 hours Total 42–54 hrs
-
Architecture Summary
Presentation Layer
- Web UI (React):
- IssueQueryEditor.tsx
- QueryResults.tsx
- QueryTemplates.tsx
- CLI (Spring Shell):
- SztabQueryCli.java
- SztabQueryShell.java
- CliOutputFormatter.java
API Layer
- IssueQueryController.java
- /api/issues/query/parse
- /api/issues/query/validate
- /api/issues/query/execute
Service Layer
- IssueQueryService.java
- Executes parsed queries
- Applies sorting and projections
- Handles aggregate queries
- QueryResult.java
- Encapsulates success and error outcomes uniformly
Shared DSL Library (sztab-query-dsl)
- Lexer, Parser, Validator
- AST model (ParsedQuery, SelectClause, WhereClause, Condition, etc.)
- Strong separation between syntax, semantics, and execution
JPA Specification Layer
- IssueSpecification.java (extended)
- Converts DSL WHERE clauses into JPA predicates
- Maps DSL fields to entity paths
- Supports temporal predicates, ranges, text search, and user/project filters
Data Access Layer
- IssueRepository.java (unchanged)
- Uses JpaSpecificationExecutor as the execution backbone
- Web UI (React):
-
The description and phased work log above represent the intended architecture and planned implementation phases for the Issue DSL, serving as a design narrative and roadmap for Release 1.8.
To keep execution and review manageable, I will track actual implementation work in focused sub-issues (DSL core library, backend execution, UI, and CLI). This issue (SZ-67) will act as the container and high-level progress tracker, and I will update it as each sub-issue is completed.
I am breaking this work into focused sub-issues to keep scope, progress, and review manageable.
Planned sub-issues:
- DSL core library: Issue DSL grammar, AST, parsing, and validation (pure Java, no Spring/JPA) (https://tigase.dev/sztab/~issues/68)
- Backend execution: REST controller, service orchestration, and JPA Specification extensions to execute DSL queries
- Issue DSL UI: DSL editor, validation feedback, and results rendering in the Issue Management UI
- SztabQuery CLI: Spring Shell–based CLI for executing Issue DSL queries from the command line
SZ-67 will act as the container and progress tracker for these sub-issues. I will update this issue as each component is completed and close it once all sub-issues are done.
⸻
-
Previous Value Current Value Open
In Progress
-
Previous Value Current Value In Progress
Closed
| Type |
New Feature
|
| Priority |
Major
|
| Assignee | |
| Version |
1.8
|
| Sprints |
n/a
|
| Customer |
n/a
|
Overview
Sztab introduces a unified, expressive Issue Query DSL that can be executed consistently across:
The DSL is designed as a first-class query language over the existing Issue domain model. It compiles DSL expressions into JPA Specifications without modifying the Issue entity or repository contracts. This ensures backward compatibility while enabling advanced querying, aggregation, projection, and reuse of saved query templates.
A new shared module (
sztab-query-dsl) encapsulates parsing, validation, and AST modeling, allowing both UI and CLI to rely on the same query semantics and error handling.See summary:
Goals Achieved
Work Log (Planned / Executed)
Phase 1 – Design & Foundations
Phase 2 – Shared DSL Library
Phase 3 – JPA Integration
Phase 4 – Service Layer
Phase 5 – API Layer
Phase 6 – Web UI
Phase 7 – CLI
Phase 8 – Demo & Polish
Demo Scenarios
Status
Release 1.8 establishes the Issue DSL as a core capability of Sztab, enabling power-user workflows while preserving existing APIs and data models. This lays the foundation for future enhancements such as saved queries, dashboards, and cross-entity querying.