Date

03 Oct 2017

7am PST / 4pm CEST

Meeting Link

Toll: +1-415-655-0001

Number: 199 948 686

Time	Item	Who
5m	Review agenda and discussion items	Sebastian Brudziński
20m	Concurrency issues - next steps?	Sebastian Brudziński
20m	Orderables update - review proposed design options	Nikodem Graczewski (Unlicensed)
15m	Shrink request/response size for batch endpoints - if enough time	Sebastian Brudziński

Link to wiki page with overview: Concurrency issues

lacking constraint checks
- where we do have one, is the error message clear?
- requistion comments
  - timestamp UI and requisition id
  - user id, requisition, status change is a UUID (status not in comment table) (*best business requirement*)
  - user id, requisiton, comment text, requisition status (status not in comment table)
  - take 2 newest status updates, dupe if text is the same (2 newest in db constraint? - postgres check constraint)
- losses and adjustments
  - (Sebastian Brudziński to research)
  - needs to work in context of the physical inventory (stock management)
UI approach to avoiding sending duplicate requests - even with constraints, we're
- once we have checks, we can detect when duplicate operations occur (now UI can detect)
- focus first on what's the cause, as we think that preventing everything might be hard to do

Versioning to an Orderable might make most sense
- version id
- update get endpoint to take version id (as parameter?)
first option seems to be most similar to immutable option
- a former favorite, an issue with immutability is for concepts which don't care about changes/history as much, e.g. FTAP.

Sebastian Brudziński to research constraint checks, talk with core team, and implement
Josh Zamor (Deactivated) to respond to orderable on ftap / version / etc
Nikodem Graczewski (Unlicensed) to continue to lead dev forum topic and followup with further requirements between the immutable (#1) and versioned (#2) options.