Changes between Initial Version and Version 1 of Prototype

Timestamp:

08/07/26 11:27:02 (9 days ago)

Author:

231285

Comment:

--

Prototype

@@ +1 @@
+= Prototype Implementation
+
+The prototype is a Go command-line application in `server/` that works against
+the `project` schema in PostgreSQL. It implements all seven use cases from
+[UseCaseModel](../P3-UseCaseModel/UseCaseModel.md) — the rubric requires at least three — with
+every database access shown as real, executed SQL. An auxiliary program in
+`bots/` simulates a live market so prices move while the prototype is running.
+
+Build, configure, run and test instructions: [BuildInstructions](BuildInstructions.md).
+
+== Implemented use-cases
+
+|| Page | Use-case || Source ||
+|| [UseCase0001Implementation](UseCase0001Implementation.md) || Register a new account || `server/auth.go` ||
+|| [UseCase0002Implementation](UseCase0002Implementation.md) || Log in || `server/auth.go` ||
+|| [UseCase0003Implementation](UseCase0003Implementation.md) || Deposit virtual funds || `server/account.go` ||
+|| [UseCase0004Implementation](UseCase0004Implementation.md) || Place market BUY order || `server/trade.go` ||
+|| [UseCase0005Implementation](UseCase0005Implementation.md) || Place market SELL order || `server/trade.go` ||
+|| [UseCase0006Implementation](UseCase0006Implementation.md) || View portfolio and history || `server/portfolio.go` ||
+|| [UseCase0007Implementation](UseCase0007Implementation.md) || Manage watchlist || `server/watchlist.go` ||
+
+Each page mirrors its P3 use-case page and adds the actual SQL emitted by the Go
+code plus a screenshot of the corresponding run against the live database.
+
+== What the prototype demonstrates about the database design
+
+- **The current price is never stored as a column.** It is always the price of
+  the most recent row in `market_trades`, read through the `v_latest_prices`
+  view. Both the user's own fills and the bot's simulated trades feed the same
+  table, so there is exactly one definition of "the price".
+- **Money movements are transactional.** Buying touches five tables — `orders`,
+  `users`, `holdings`, `transactions`, `market_trades` — inside one transaction.
+  A failed balance check rolls the whole thing back: after a rejected purchase
+  there is no order row, no ledger entry and no holding. This is verified in the
+  failure-path tests in [BuildInstructions](BuildInstructions.md).
+- **Constraints do real work.** `UNIQUE (user_id, crypto_id)` on `holdings` is
+  what makes the `INSERT … ON CONFLICT DO UPDATE` upsert possible, so the
+  weighted-average entry price is recomputed by the database in one statement
+  instead of by a read-modify-write in application code.
+- **No identifiers are ever typed.** Markets are listed with their prices before
+  any choice is made, and everything else is selected by symbol.
+
+== Known limitations
+
+Deliberately out of scope for a first prototype, and the natural content of the
+later phases:
+
+- Only `market` orders execute. `limit` is accepted by the schema
+  (`orders.type`) but the matching logic is not implemented.
+- Passwords are SHA-256 without a salt. Adequate to demonstrate that the
+  password itself is never stored; not adequate for real use. A proper
+  password hash belongs in P9 (security).
+- Money is handled as `float64` in Go while the database columns are `numeric`.
+  All arithmetic that must be exact — the weighted average — is done in SQL for
+  that reason, but the Go side would need a decimal type for real use.
+- There is no connection pooling configuration and no explicit isolation level;
+  both are P8 topics.