Page Comparison

...

https://www.uberconference.com/villagereach-isg

Optional dial in:
Dial in: 213-493-0531
PIN: 74762

Attendees

• Josh Zamor

• Elias Muluneh

• Nick Reid (Deactivated)
• Ben Leibert
• Brandon Bowersox-Johnson
• Pengfei Cui (Deactivated)
• Paweł Gesek
• Sebastian Brudziński
• Nikodem Graczewski (Unlicensed)
• Chongsun Ahn (Unlicensed)
• Darius Jazayeri (Unlicensed)
• Jeff Xiong (Unlicensed)

Goals

• Dev forum topics:
  • Discuss DELETE as archive example
  • stock management design
  • pagination
  • versioning

...

Delete as Archive example

...

• DELETE operations shouldn't be allowed
• Resources should support archiving/de-activating them.  Resources such as /api/facilities/{id} do this via facility start/stop dates, or program supported active dates.  /api/users/{id} does this via the field active.
• Resource search endpoints would by default return only non-archived items.  Consequently there would need to be special search endpoints or query parameters to find archived items (edge case).
  
  • NOTE:  schedule or period search or products endpoints MAY use search to get a specific resource.  i.e. we should check that we don't use the search endpoint internally to the service to find a specific resource because with this default convention we may not find what we're looking for and therefore a GET/PUT/POST would return a 404.  We should check these search endpoints for what they do when they look for a specific resource when we implement the archive operation for that resource.
• Consumers of resources would have to understand that the resource may become archived.

...

Deleting Reference Data is a particularly bad idea - not only will referential integrity within Reference Data often prevent it, but cross-service or even cross-system references can break silently and expensively.  Away from Reference Data, many Resources, such as Stock Card line items, simply can't be deleted for principles of accountability.

NOTE on deleteing a Requisition in v2:  v2 deleted an initiated Requisition when something like the Req. Template or approved products changed.  The goal was to remove Requisitions that we're recently created using essentially an outdated set of information.  e.g.  the template changed, so don't fill in that new Requisition rural health clinic, you have the old template.  Another addition was a DB-level constraint for ensuring that a Requisition was unique by Facility, Program, Period, etc.  If an "archived" flag were added, that constraint would have to expand to understand that archived flag.

Josh's proposal:  in v3 we should be following our more domain-oriented design, and encapsulating that knowledge of how/when a domain object is archived within the domain class and have that reflected in the Repositories operations.  In the above the domain class would have the knowledge on how/when to archive and its repository would provide for search operations and enforce uniqueness rules.  Uniqueness rules can be aided by JPA annotations such as @Table, custom repository implementations or perhaps less favorably by @PrePersist type annotations.

Action items