From 15e66574729d0f80c871adb9201fc5dad51b7476 Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Wed, 6 May 2020 22:03:46 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 5683f000..e688e848 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -72,8 +72,9 @@ CURRENT TODOs CURRENT ITEM: BIZ OBJECT STUBBING FOR EXPORT TESTING OF HUGE ATTACHMENTS AND WIKI AND ATTACHED DOCS -TEST: Is my ef core relationship enough with just annotations and navigation properties or do I need to define shit further - - Test create, retrieve, cascade delete +TEST: Proposed workorder structure and routes + See below PROPOSAL section + TEST EXPORT BIG DATABASE WITH TONS OF ATTACHMENTS @@ -87,6 +88,12 @@ todo: PLANNING WORKORDER considerations: QUESTIONS: Why do I need to make a wo first before I can update it? (i.e. why did I make a CREATE route?) + BUSINESS RULES (v7) + In reality there are almost no business rules in v7 workorder graph. + Only serious one is woitempart requires serial if serialized + Rest are all related to length of fields, required fields, date order etc and only a few of those to boot + Looks like this is not an issue regarding v7 stuff at all + DEPENDENCIES Workorder is not dependent on it's children for anything WoItem is not dependent on any of it's children @@ -119,10 +126,14 @@ todo: PLANNING WORKORDER considerations: TEST Do a practical test of a mocked wo, woitem, woitemlabor or whatever, see how it would be updated, fetched concurrency checking etc QUESTIONS: - How best to update, in bits and pieces? + How to do CRUD efficiently with a workorder and client? - PROPOSAL: Send only changes in whole graph from client with an OP (for "operation") flag at each level indicating to change that part or not, a flag? + PROPOSAL: + CREATE: + CreateFromxxxx routes (NO TEST REQUIRED) + POST accepts workorder full graph (test) + UPDATE: Send only changes in whole graph from client with an OP (for "operation") flag at each level indicating to change that part or not, a flag? WO (OP flag=no change, no concurrency token, basically empty but for the fields that hold the descendents that are changed) woitem 0 (OP flag="Delete" and concurrency token, no other data with it, just the id and flag and ctoken) woitem 1 (OP flag ="update", all fields as in a "put" operation, nothing left out, assumed all are changed)