Changes between Version 2 and Version 3 of Prototype

Timestamp:

08/07/26 11:31:39 (9 days ago)

Author:

231285

Comment:

--

Prototype

@@ -1 @@
-= Prototype Implementation
+= 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.
+The prototype is a Go command-line application in
+[https://github.com/StefanTrsunov/bp/tree/main/server server/] that works against the `project`
+schema in PostgreSQL. It implements all seven use cases from
+[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCaseModel.md UseCaseModel]
+– the rubric requires at least three – with every database access shown as real, executed SQL.
+An auxiliary program in [https://github.com/StefanTrsunov/bp/tree/main/bots bots/] simulates a
+live market so prices move while the prototype is running.
 
-Build, configure, run and test instructions: [BuildInstructions](BuildInstructions.md).
+Build, configure, run and test instructions:
+[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/BuildInstructions.md BuildInstructions].
 
-== Implemented use-cases
+All pages listed below, together with the screenshots of each run, are kept in the project's
+GitHub repository, [https://github.com/StefanTrsunov/bp StefanTrsunov/bp], under
+`docs/P4-Prototype/`.
 
-|| 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` ||
+== Implemented use-cases ==
 
-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.
+||=Page=||=Use-case=||=Source=||
+||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0001Implementation.md UseCase0001Implementation]||Register a new account||[https://github.com/StefanTrsunov/bp/blob/main/server/auth.go server/auth.go]||
+||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0002Implementation.md UseCase0002Implementation]||Log in||[https://github.com/StefanTrsunov/bp/blob/main/server/auth.go server/auth.go]||
+||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0003Implementation.md UseCase0003Implementation]||Deposit virtual funds||[https://github.com/StefanTrsunov/bp/blob/main/server/account.go server/account.go]||
+||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0004Implementation.md UseCase0004Implementation]||Place market BUY order||[https://github.com/StefanTrsunov/bp/blob/main/server/trade.go server/trade.go]||
+||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0005Implementation.md UseCase0005Implementation]||Place market SELL order||[https://github.com/StefanTrsunov/bp/blob/main/server/trade.go server/trade.go]||
+||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0006Implementation.md UseCase0006Implementation]||View portfolio and history||[https://github.com/StefanTrsunov/bp/blob/main/server/portfolio.go server/portfolio.go]||
+||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0007Implementation.md UseCase0007Implementation]||Manage watchlist||[https://github.com/StefanTrsunov/bp/blob/main/server/watchlist.go server/watchlist.go]||
 
-== What the prototype demonstrates about the database design
+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. The screenshots are committed
+alongside the pages, in
+[https://github.com/StefanTrsunov/bp/tree/main/docs/P4-Prototype/screenshots docs/P4-Prototype/screenshots/].
 
-- **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.
+== What the prototype demonstrates about the database design ==
 
-== Known limitations
+ * '''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
+   [https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/BuildInstructions.md BuildInstructions].
+ * '''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.
 
-Deliberately out of scope for a first prototype, and the natural content of the
-later phases:
+== Known limitations ==
 
-- 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.
+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.