| | 1 | = Advanced Database Development AI Usage = |
| | 2 | |
| | 3 | == Name of AI service/solution that was used == |
| | 4 | |
| | 5 | '''Claude Code''' (Anthropic) |
| | 6 | |
| | 7 | * '''URL:''' `https://claude.com/claude-code` |
| | 8 | * '''Type of service/subscription:''' Claude subscription, model Claude Opus 5.5. |
| | 9 | |
| | 10 | == Final result == |
| | 11 | |
| | 12 | === Diagram === |
| | 13 | |
| | 14 | No new diagram. The data model gains four columns and one table, all listed under "Changes to |
| | 15 | earlier phases" in [wiki:AdvancedDatabaseDevelopment]: |
| | 16 | |
| | 17 | * `users.reserved_balance`; |
| | 18 | * `orders.filled_quantity` (with the status `partially_filled`); |
| | 19 | * `market_trades.buy_order_id` and `market_trades.sell_order_id`; |
| | 20 | * `order_events`. |
| | 21 | |
| | 22 | The optional link from a trade to the orders it filled is a new relationship, which |
| | 23 | [wiki:ERModel] and |
| | 24 | [wiki:RelationalDesign] must show as well. |
| | 25 | |
| | 26 | === Results in details / description === |
| | 27 | |
| | 28 | My requirements, given to the AI as a list: |
| | 29 | |
| | 30 | * complex order consistency: no invalid state changes, filled and remaining quantities consistent, finished orders never processed again; |
| | 31 | * balance and order consistency: active orders consistent with reserved money and assets, no inconsistent balance states from order operations; |
| | 32 | * trade consistency: trades only between valid compatible orders, never more than the remaining quantity, orders, trades and balances kept consistent; |
| | 33 | * which kinds of triggers, procedures, functions and views to build; |
| | 34 | * a background job only if it is genuinely relevant; |
| | 35 | * basic column constraints kept out of P7. |
| | 36 | |
| | 37 | The AI: |
| | 38 | |
| | 39 | * Checked the existing schema against those requirements. It found that three of them could not be expressed without small additions: there was no filled quantity, no place for reserved cash, and no link from a trade to its orders. It added only the four columns listed above and the event table. |
| | 40 | * For every feature, wrote down the business rule, why it is non-trivial, which PostgreSQL feature implements it and which tables it affects. This is the structure I asked for, and [wiki:AdvancedDatabaseDevelopment] follows it. |
| | 41 | * Implemented `advanced_db.sql`: |
| | 42 | * 5 row triggers (order lifecycle, order events, trade validation, trade fill, trade immutability); |
| | 43 | * 3 deferred constraint triggers (reserved cash, reserved crypto, cash equals ledger); |
| | 44 | * the functions `place_order`, `match_order`, `execute_trade`, `cancel_order`, `order_reservation` and `latest_price`; |
| | 45 | * 4 views; |
| | 46 | * the background job `fill_marketable_orders`. |
| | 47 | * Checked the faculty server before choosing how to schedule the background job. There is no `pg_cron` and the role is not a superuser, so the job is a function that the bot process calls after every round of price ticks. |
| | 48 | * Adapted the two data scripts to the new consistency rules and verified that both P6 report outputs stay exactly as documented. |
| | 49 | * Wrote `advanced_db_tests.sql`: a trading story with 41 checks, rolled back at the end. It ran them until all passed. The one failure along the way was in the test itself: a check read the data in the same statement as the job it was checking. |
| | 50 | * Wired the prototype to use the new functions: |
| | 51 | * order placement is a single `place_order` call, with market or limit orders; |
| | 52 | * the order book, open orders and cancel are available from the menu, with cancel picked from a numbered list; |
| | 53 | * the balance screen shows reserved cash; |
| | 54 | * the bot runs the job. |
| | 55 | |
| | 56 | All of this was verified through the CLI and with the bot running. |
| | 57 | * Wrote this documentation. |
| | 58 | |
| | 59 | == Summary of AI involvement == |
| | 60 | |
| | 61 | ||= =||= This session — 2026-09-24 =|| |
| | 62 | || '''What I brought''' || The P7 requirements for !EduBerza: order, balance and trade consistency, the kinds of triggers, procedures and views, and the condition on the background job || |
| | 63 | || '''What the AI did''' || Turned the requirements into concrete rules on the existing schema, implemented and tested them, wired them into the prototype, wrote the documentation || |
| | 64 | || '''What I decided''' || The requirements themselves; to discard the AI's earlier, self-proposed P7 version (see the log) and redo the phase from my requirements; to keep the schema changes minimal || |
| | 65 | |
| | 66 | == Entire AI usage log == |
| | 67 | |
| | 68 | === 2026-09-24 — earlier attempt, discarded === |
| | 69 | |
| | 70 | Earlier in the same session I had pasted the P7 and P8 rubrics without ideas of my own, and the |
| | 71 | AI proposed and implemented a P7 of its own design: custom domains, an append-only ledger, |
| | 72 | candles derived from trades and a maintenance job. Before submitting anything I decided to redo |
| | 73 | the phase from my own requirements, and asked for that version to be reverted. None of it |
| | 74 | remains in the project. It is mentioned here only so the log is complete. |
| | 75 | |
| | 76 | === 2026-09-24 — this phase === |
| | 77 | |
| | 78 | '''Prompt (student, verbatim):''' |
| | 79 | > P7 requirements are: |
| | 80 | > |
| | 81 | > more complex data constraints and consistency requirements |
| | 82 | > business scenarios that require special database checks |
| | 83 | > triggers |
| | 84 | > stored procedures and functions |
| | 85 | > views |
| | 86 | > background jobs |
| | 87 | > documentation of the implementation |
| | 88 | > |
| | 89 | > Basic column constraints such as NOT NULL, UNIQUE, CHECK, PRIMARY KEY, and basic foreign keys |
| | 90 | > are Phase P2 and must NOT be proposed as P7 features. |
| | 91 | > |
| | 92 | > Based on my existing !EduBerza database, identify and implement only genuinely NON-TRIVIAL P7 |
| | 93 | > requirements. |
| | 94 | > |
| | 95 | > Focus on these types of requirements: |
| | 96 | > |
| | 97 | > Complex order consistency |
| | 98 | > Prevent invalid order state changes. |
| | 99 | > Ensure filled/remaining quantities stay consistent. |
| | 100 | > Prevent cancelled or completed orders from being processed again. |
| | 101 | > Balance and order consistency |
| | 102 | > Ensure active orders are consistent with reserved virtual money/assets. |
| | 103 | > Prevent inconsistent balance states caused by order operations. |
| | 104 | > Trade consistency |
| | 105 | > Ensure a trade can only happen between valid compatible orders. |
| | 106 | > Ensure trade quantity cannot exceed the remaining order quantity. |
| | 107 | > Keep orders, trades, and balances consistent. |
| | 108 | > Triggers |
| | 109 | > Create triggers only for automatic database behavior that is genuinely required, such as: |
| | 110 | > automatic validation of complex business rules |
| | 111 | > automatic order status changes |
| | 112 | > automatic recording of important order/trade events |
| | 113 | > Stored procedures/functions |
| | 114 | > Create procedures/functions for complex database operations such as: |
| | 115 | > placing an order with the necessary consistency checks |
| | 116 | > executing a trade while updating all related data consistently |
| | 117 | > Views |
| | 118 | > Create useful views for derived application data, such as: |
| | 119 | > current order book |
| | 120 | > active orders |
| | 121 | > trader portfolio/balances |
| | 122 | > order/trade history |
| | 123 | > |
| | 124 | > Do not recreate reports that were already implemented in P6 unless a view is needed |
| | 125 | > specifically as part of P7. |
| | 126 | > |
| | 127 | > Background jobs |
| | 128 | > Implement a meaningful background database job only if it is relevant to the existing |
| | 129 | > !EduBerza design. |
| | 130 | > Do not create an artificial background job just to satisfy the requirement. |
| | 131 | > |
| | 132 | > For every proposed P7 feature, explain: |
| | 133 | > |
| | 134 | > the business rule |
| | 135 | > why it is non-trivial |
| | 136 | > which PostgreSQL feature should implement it |
| | 137 | > which existing tables it affects |
| | 138 | > |
| | 139 | > Then implement the selected P7 features in the existing project without redesigning the |
| | 140 | > database unnecessarily. |
| | 141 | > |
| | 142 | > Finally, document: |
| | 143 | > |
| | 144 | > complex data requirements |
| | 145 | > triggers |
| | 146 | > stored procedures/functions |
| | 147 | > views |
| | 148 | > background jobs |
| | 149 | > how each one maintains consistency or enforces a business rule |
| | 150 | > examples/tests proving that the rules work |
| | 151 | > |
| | 152 | > Keep the implementation strictly within P7. |
| | 153 | |
| | 154 | (The first time I sent it the message was interrupted; I sent it again, followed by "and revert |
| | 155 | the previous changes".) |
| | 156 | |
| | 157 | '''Response (AI, summarised):''' |
| | 158 | |
| | 159 | * '''Revert.''' It restored every file changed by the discarded attempt to the last commit and deleted the files that attempt had created. It kept the SSH connection support (from before P7) and my own uncommitted edits. |
| | 160 | * '''Analysis.''' It reported that three requirements need data the schema doesn't have — a filled quantity, a reserved cash balance, and trade-to-order links — and added exactly those (`orders.filled_quantity` plus status `partially_filled`, `users.reserved_balance`, `market_trades.buy_order_id`/`sell_order_id`), plus `order_events` for the automatic event recording. |
| | 161 | * '''Design:''' |
| | 162 | * A trade is always a `market_trades` row naming the orders it fills. Triggers on that table validate compatibility and fill the orders; the order's status is derived from its filled quantity by the order trigger. |
| | 163 | * `filled_quantity` may only change while a trade is being recorded, which is detected through a transaction-local setting. |
| | 164 | * The three balance rules are deferred constraint triggers, because every legitimate operation breaks them between its statements. |
| | 165 | * Placing an order reserves first, then matches against the order book (price–time priority), then fills the marketable remainder from the simulated market. |
| | 166 | * Rounding of reservations is defined once (`order_reservation`), so placing, filling, cancelling and checking always agree. |
| | 167 | * '''Background job.''' It argued the job is relevant rather than artificial: the market price is moved by the simulator, and without the job resting limit orders would never fill once the price reaches them. It explained why a trigger on the bot's price ticks would be the wrong place for this work. |
| | 168 | * '''Verification''' (local PostgreSQL 17 in Docker only, never the faculty database): |
| | 169 | * both P6 reports return the documented numbers; |
| | 170 | * the P6 demo script can be re-run without doubling anything; |
| | 171 | * the test story passes 41 of 41; |
| | 172 | * through the CLI: a limit sell resting in the book, a crossing limit buy trading at the resting price with the difference refunded, a market buy filled partly from the book and partly from the market, the order book, open orders, and cancelling with the reservation released; |
| | 173 | * with the bot running, the job filled a resting limit order once the price walk reached it. |
| | 174 | * '''Documentation.''' It wrote [wiki:AdvancedDatabaseDevelopment] and this log, with the SQL on the page taken automatically from `advanced_db.sql` so the two cannot differ, together with the faculty-site (wiki) versions of both pages. |
| | 175 | |
| | 176 | '''What I decided:''' the requirements are mine. I kept the AI's minimal schema additions and its |
| | 177 | design for fulfilling them, and asked for no changes to it before it was implemented. |
