AccountOrderSchemaV3.php
Source file: backend/database/migrations/AccountOrderSchemaV3.php
Module: backend-database
Size: 74 lines
SHA-256: c1d4c1c70cbe3b3851f543e04e2ed6eb27197b732edc8235d03178e13debad6a
Responsibility
Implements repositories, schema definitions and migration contracts; MariaDB owns originating customer record time.
Declared entry points
AccountOrderSchemaV3— source line 10.VERSION— source line 12.statements— source line 14.
Imports and dependencies
- Line 4:
use Hslg\Backend\Database\TableNames;
Behaviour and audit locations
- Line 8:
* revision is used. This is NOT a priced order or Stripe settlement schema. - Line 27:
created_at datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), - Line 28:
updated_at datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6), - Line 37:
created_at datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), - Line 47:
created_at datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), - Line 54:
window_start datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), - Line 62:
idempotency_key char(36) NOT NULL, - Line 66:
created_at datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
Accounts and unpriced drafts
This schema layer introduces HSLG-owned account credentials, sessions, verification challenges, rate-limit records and draft-order persistence. Session state and idempotent drafts are transactional structures; they must not be implemented using customer-field newest-row semantics. Staging tests should include schema upgrades from earlier releases, unique key collisions and preservation of existing profile records.
Relationship to the system
This page is the file-level source reference, not the architecture rationale. Read the module explanation, the corresponding architecture decision and user guide before changing behaviour. Names and line locations above are extracted from this exact source version; they are reference points, not proof that an external service or a phone feature works.
Change verification
Review the entry points and errors in this file, then run the module’s associated tests, source dependency gate, history gate and documentation coverage check. If the file changes an API response, user interaction, data model, deployment or third-party dependency, revise those human explanations and disaster recovery/licensing when relevant. Do not infer actual native or external API operation from source presence.