Jacek Pyziak
c489891d15
- Implemented OrdersRepository for handling order data with pagination, filtering, and sorting capabilities. - Added methods for retrieving order status options, quick stats, and detailed order information. - Created OrderStatusRepository for managing order status groups and statuses, including CRUD operations and sorting. - Introduced a bootstrap file for test environment setup and autoloading.
1.7 KiB
1.7 KiB
Orders Schema Draft (Generic)
Context
- This is a generic schema proposal for external orders import/sync.
- API docs from Apilo were used only as an example of a rich order payload shape.
- Target is integration-agnostic storage (no vendor lock in table/column names).
Proposed tables
ordersorder_addressesorder_itemsorder_paymentsorder_shipmentsorder_documentsorder_notesorder_status_historyorder_tags_dictorder_tag_linksintegration_order_sync_state
SQL draft:
Design principles
- Keep one row per imported source order in
orders. - Store child collections in dedicated tables (1:N).
- Keep source IDs and selected business scalars as first-class columns.
- Keep raw payload snapshots (
payload_json) for diagnostics and replay safety. - Keep import idempotent:
- unique
(integration_id, source_order_id)inorders, - unique child keys per order and source child ID.
- unique
- Keep event timeline in separate
order_status_history.
Why these extra tables
order_status_history: audit + timeline reconstruction + sync debugging.integration_order_sync_state: robust incremental fetch cursor.order_tags_*: proper many-to-many, easy filtering and deduplication.
Notes before implementation
- Draft is intentionally in
database/drafts(not auto-run by Migrator). - Before production migration:
- confirm source-specific mapping in service layer,
- confirm retention policy for
payload_json, - decide merge strategy for child rows (upsert by source IDs vs hard refresh per sync).