mklinik / bank Goto Github PK

• implementation
• error when requesting non-existent account
• tests

We are storing the balance as postgres type money, which has a precision of two decimal places. What happens if someone tries to deposit an amount smaller than that, for example 0.001? What should happen?

How to implement consistent error handling?

See for example the places where Integer/parseInt is used. What if this fails? Should somehow probably give 400 bad request.

There are two points where parameters can be verified: the handler and the database operation. Some parameters can be verified in the handler, others can only be verified in the database operation. For example, that withdrawn amount is positive can be handled is both, but that an account exists can only be handled in the database operation. If there is enough balance to withdraw an amount can only be checked in the database operation.

Other errors, like success of Integer/parseInt do not make sense in the database operation. This should be checked in the handler.

Conclusion: some parameters should be checked in the handler, some in the database operation.

In any case, the handler should generate an error response. What is the best way to communicate parameter verification failure from the database operation to the handler? Either return value, or exception?

How to tell the handlers which database to use for tests and production?

see also

• {:builder-fn rs/as-unqualified-lower-maps}
• SQL as
• camel-snake-kebab note here https://cljdoc.org/d/seancorfield/next.jdbc/1.1.613/doc/getting-started
• https://cljdoc.org/d/seancorfield/next.jdbc/1.1.613/doc/getting-started/result-set-builders

• implementation
• tests

Default postgres is Read Committed. Is this enough for us, or do we need something stricter? How to verify and test? Do different features need different isolation levels? Deposit vs withdraw vs transfer?

The audit log opens a new can of worms. Creating audit logs should belong to a transaction. There should not come an audit log creation from another transaction in between.

Transactions T and audit logs L come in pairs:

T1
L1

If two transactions happen concurrently, logging should never come between! This should never happen:

T1
T2
L1
L2

Or worse, the order of logs is different than the order of transactions:

T1
T2
L2
L1

I think this means transactions and logs must be inside a serializable SQL transaction!

Some of the sql commands in bank/database are susceptible to SQL injections.

• prove it by writing test cases that perform SQL injections
• fix them

["select * from address where id = ?" 2] see https://cljdoc.org/d/seancorfield/next.jdbc/1.1.613/doc/getting-started

Maybe use prepared statements? Read next.jdbc doc about it.

• deposit only positive amounts

• only transfer between existing accounts
• cannot transfer to self
• resulting balance should not fall below zero

• withdraw only positive amounts
• withdraw not more than what's on the account
• withdraw only from existing account