|
1 | 1 | # Roadmap |
2 | 2 |
|
3 | | -This roadmap tracks the improvement work for `freshsauce/model`. |
| 3 | +This roadmap now tracks only the remaining optional backlog for `freshsauce/model`. |
4 | 4 |
|
5 | | -Current status: |
| 5 | +Phases 1 through 3 are complete, and Phase 4.1 through 4.3 have been delivered. |
6 | 6 |
|
7 | | -1. Phase 1 is complete. |
8 | | -2. Phase 2 is complete. |
9 | | -3. Phase 3 is complete. |
10 | | -4. Phase 4 remains optional and has not been started. |
11 | | - |
12 | | -The sequencing remains intentional: |
13 | | - |
14 | | -1. Fix correctness issues before expanding the API. |
15 | | -2. Improve developer ergonomics without turning the library into a heavyweight ORM. |
16 | | -3. Tighten quality and portability before considering broader feature growth. |
17 | | -4. Add optional features only where they preserve the package's lightweight position. |
18 | | - |
19 | | -## Principles |
20 | | - |
21 | | -- Keep PDO-first escape hatches intact. |
22 | | -- Prefer additive changes with low migration cost. |
23 | | -- Tighten behavior with tests before changing public APIs. |
24 | | -- Avoid feature growth that pushes the library toward framework-scale complexity. |
25 | | - |
26 | | -## Phase 1: Core correctness and safety |
27 | | - |
28 | | -Status: completed |
29 | | - |
30 | | -Summary: |
31 | | - |
32 | | -- Fixed serialization, zero-like primary key handling, invalid dynamic finder failures, and empty-array query behavior. |
33 | | -- Replaced generic exceptions with a small library exception hierarchy. |
34 | | -- Added regression coverage for the above edge cases. |
35 | | - |
36 | | -## Phase 2: API ergonomics and typing |
37 | | - |
38 | | -Status: completed |
39 | | - |
40 | | -Summary: |
41 | | - |
42 | | -- Added instance-aware validation hooks with legacy compatibility. |
43 | | -- Added optional strict field handling and focused query helpers. |
44 | | -- Tightened typing, static analysis, and public documentation around the preferred API. |
45 | | - |
46 | | -## Phase 3: Quality, portability, and maintenance |
47 | | - |
48 | | -Status: completed |
49 | | - |
50 | | -Summary: |
51 | | - |
52 | | -- Expanded cross-driver integration coverage for connection sharing, custom keys, metadata refresh, timestamp behavior, and PostgreSQL schema-qualified tables. |
53 | | -- Added `refreshTableMetadata()` and made UTC timestamp behavior explicit. |
54 | | -- Normalized no-op update handling while preserving single-row primary key update expectations. |
55 | | - |
56 | | -## Phase 4: Optional feature expansion |
57 | | - |
58 | | -Goal: add features that help real applications, but only if they fit the package's lightweight position. |
59 | | - |
60 | | -Priority: lower |
61 | | - |
62 | | -Phases 1 through 3 are complete, so this is now the remaining backlog. |
63 | | - |
64 | | -### Candidate 4.1: Transaction helpers |
65 | | - |
66 | | -Possible scope: |
67 | | - |
68 | | -- `transaction(callable $callback)` |
69 | | -- pass through `beginTransaction()`, `commit()`, `rollBack()` wrappers |
70 | | - |
71 | | -Why: |
72 | | -This adds practical value without changing the core model shape. |
73 | | - |
74 | | -### Candidate 4.2: Configurable timestamp columns |
75 | | - |
76 | | -Possible scope: |
77 | | - |
78 | | -- opt-in timestamp column names |
79 | | -- disable automatic timestamps per model |
80 | | - |
81 | | -Why: |
82 | | -The current `created_at` / `updated_at` convention is convenient but rigid. |
83 | | - |
84 | | -### Candidate 4.3: Attribute casting |
85 | | - |
86 | | -Possible scope: |
87 | | - |
88 | | -- integer |
89 | | -- float |
90 | | -- boolean |
91 | | -- datetime |
92 | | -- JSON array/object |
93 | | - |
94 | | -Why: |
95 | | -Casting improves ergonomics substantially without requiring relationships or a large query layer. |
96 | | - |
97 | | -### Candidate 4.4: Composite keys or relationship support |
| 7 | +## Remaining item: 4.4 Composite keys or relationship support |
98 | 8 |
|
99 | 9 | Why this is last: |
100 | | -This is where complexity rises sharply. It should only happen if the maintainer wants the library to move beyond lightweight active-record usage. |
| 10 | + |
| 11 | +- This is where complexity rises sharply. |
| 12 | +- It should only happen if the maintainer wants the library to move beyond lightweight active-record usage. |
101 | 13 |
|
102 | 14 | Recommendation: |
103 | 15 |
|
104 | 16 | - Do not start here by default. |
105 | | -- Re-evaluate only after the earlier phases have shipped and real user demand is clear. |
106 | | - |
107 | | -## Suggested issue order |
108 | | - |
109 | | -If this work is split into GitHub issues, the most practical order is: |
110 | | - |
111 | | -1. Add transaction helpers. |
112 | | -2. Add configurable timestamp column support. |
113 | | -3. Add attribute casting. |
114 | | -4. Re-evaluate whether composite keys or relationship support are warranted. |
115 | | - |
116 | | -## Suggested release strategy |
117 | | - |
118 | | -- Release 1: Phase 1 correctness and exception work. Shipped. |
119 | | -- Release 2: Phase 2 ergonomics, typing, and documentation updates. Shipped. |
120 | | -- Release 3: Phase 3 portability and maintenance hardening. Shipped. |
121 | | -- Release 4: optional feature work only if it still fits the package scope. |
| 17 | +- Re-evaluate only after clear real-world demand. |
| 18 | +- Preserve the package's lightweight, PDO-first position if any further expansion happens. |
122 | 19 |
|
123 | 20 | ## Out of scope unless demand changes |
124 | 21 |
|
|
0 commit comments