54 lines
3.1 KiB
YAML
54 lines
3.1 KiB
YAML
|
decisions_log:
|
||
|
|
- question: >
|
||
|
|
`notes` here only cover Settings; no entities/columns have been sketched yet for
|
||
|
|
Users, Roles, Permissions, Pages, Posts, Media, Comments, or Content Versions
|
||
|
|
(History). Should the core schema be drafted in this section before
|
||
|
|
MILESTONES.yaml is written, given how many features depend on it?
|
||
|
|
decision: >
|
||
|
|
Yes — the core schema has been drafted above (`Database Tables`), covering
|
||
|
|
Settings, Users, Roles, Permissions, Role_Permission, User_Role, Pages,
|
||
|
|
Page_Versions, Posts, Post_Versions, Media, and Comments.
|
||
|
|
rationale: >
|
||
|
|
Gives MILESTONES.yaml concrete table/column definitions to build migrations
|
||
|
|
from, instead of inferring the schema from feature descriptions alone.
|
||
|
|
- question: >
|
||
|
|
Should a cross-cutting convention for audit/timestamp columns (`created_at`/
|
||
|
|
`updated_at`, and who created/last edited a record) be documented once entities
|
||
|
|
are sketched out, so every migration follows the same pattern?
|
||
|
|
decision: >
|
||
|
|
Partially applied so far: Pages, Page_Versions, Posts, Post_Versions, and
|
||
|
|
Comments already follow a `created_at`/`created_by`/`updated_at`/`updated_by`
|
||
|
|
pattern. Users, Roles, Permissions, Role_Permission, User_Role, and Media do
|
||
|
|
not yet have any `created_at`/`updated_at` columns (see the new suggestion
|
||
|
|
below flagging this gap).
|
||
|
|
rationale: >
|
||
|
|
Records the convention actually in use today, rather than assuming it was
|
||
|
|
applied uniformly across every table.
|
||
|
|
- question: >
|
||
|
|
Should the suggested `created_at`/`created_by`/`updated_at`/`updated_by`
|
||
|
|
columns be added to Users, Roles, Permissions, Role_Permission, User_Role, and
|
||
|
|
Media (see `suggestions` below)?
|
||
|
|
decision: >
|
||
|
|
Yes, accepted and applied — Users, Roles, Permissions, Role_Permission, and
|
||
|
|
User_Role already carried the columns above; Media has now also been given the
|
||
|
|
same `created_at`/`created_by`/`updated_at`/`updated_by` columns, so every
|
||
|
|
table in the schema now follows the convention. `User_Totp`, `User_password_reset`,
|
||
|
|
and `User_email_verification` are purposely missing the `created_by` and `updated_by`
|
||
|
|
fields, as these are system generated and not tied to specific users.
|
||
|
|
rationale: >
|
||
|
|
Closes the last gap (Media) so audit/timestamp tracking is consistent across
|
||
|
|
every table, matching the convention already used on Pages/Page_Versions/
|
||
|
|
Posts/Post_Versions/Comments.
|
||
|
|
- question: What database engine will be used?
|
||
|
|
decision: >
|
||
|
|
Support for MySQL/MariaDB through PDO connections.
|
||
|
|
rationale: >
|
||
|
|
Supporting multiple engines provides flexibility for different deployment
|
||
|
|
scenarios while maintaining a consistent interface through PDO.
|
||
|
|
- question: How will data migrations be handled?
|
||
|
|
decision: >
|
||
|
|
Data migrations will be implemented using Laravel Eloquent migrations, with each plugin having
|
||
|
|
its own migration files.
|
||
|
|
rationale: >
|
||
|
|
This approach allows plugins to manage their own database schema changes
|
||
|
|
while providing a centralized migration management system.
|