Versions Compared

Old Version 1

changes.mady.by.user Mike Gorrell

Saved on

compared with

New Version Current

changes.mady.by.user Mike Gorrell

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Attendees

Discussion items

TimeItemWhoNotes

Optimistic Record LockingTC

Review issues (Tech Debt - DEBT-1, UXPROD-1752)  and discuss short term actions:

There was 

Jira Legacy
serverSystem JIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODINVSTOR-516
 which should be fixed by 
Jira Legacy
serverSystem JIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyRMB-388

These issues will be resolved based on serializing activity as opposed to a fundamental design change to address optimistic locking.

Addressing optimistic locking is not likely to be addressed by a single/core team, but likely all backend teams would need to make modifications. In other words, a very big deal. Per UXPROD-1752:

  • optimistic locking – each record state is marked with a "version number" (or a timestamp, hash, etc) which is returned to the client along with the record. The client includes the version number during the update and the server checks that the version hasn't changed before it writes the record back. If the record is dirty (version doesn't match) the update is aborted. In practice for a REST API (typical FOLIO uses case) this means using ETag with a combination of If-Match conditional request and 412 (precondition failed) and 409 (conflict) error codes.

Note that ETags (above) approach may not solve all use cases (batch, pub-sub oriented), etc.

Could "define the requirements"... and put the burden on modules/teams to come up with their own solution... but then we'd have the challenge/cost of potentially independent solutions and separate implementations.

ACTIONS:

1) Ask Jakub Skoczen when UXPROD-1752 might fit on Core:Platform's roadmap

2) Define a recommended standard/approach (e.g. ETags)

3) Get confirmation of this issue's urgency


 Plan to review Tech Debt

Mike Gorrell  

Discuss how we will go about reviewing Tech Debt 

3 steps:

1) Triage the list; what's active, what's the priority, etc. - ACTION - TC members to review list, update/close/etc. in prep for meeting September 9 where we will review entire list together

2) Assign appropriate items to TC members (based on priority, etc.)

3) Define the expectations of TC


Updates on open itemsTC

UI Testing: Zak Burke

  • Dilemma is that Big Test 2.0 is not ready and while it represents an opportunity we have needs right now.
  • No matter what we are looking at making changes to existing tests in order to move to a new/updated framework
  • Might be OK to have multiple frameworks
  • Expect recommendation in the next 2 weeks

Defining Data Types (reference data): Jakub Skoczen

Others?

  • Initial meeting is set for tomorrow (8/29)

SAML/SSO issues: Tod Olson

  • Conversation starting

NEXT WEEK
Architectural Blueprint review