admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2020-05-06 22:08:14 +00:00
parent 15e6657472
commit f30b28066d
1 changed files with 18 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
ayanova/devdocs/todo.txt
View File

@@ -94,6 +94,7 @@ todo: PLANNING WORKORDER considerations:
Rest are all related to length of fields, required fields, date order etc and only a few of those to boot 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 Looks like this is not an issue regarding v7 stuff at all
DEPENDENCIES DEPENDENCIES
Workorder is not dependent on it's children for anything Workorder is not dependent on it's children for anything
WoItem is not dependent on any of it's children WoItem is not dependent on any of it's children
@@ -129,11 +130,21 @@ todo: PLANNING WORKORDER considerations:
How to do CRUD efficiently with a workorder and client? How to do CRUD efficiently with a workorder and client?
PROPOSAL: PROPOSAL TO TEST:
CREATE: Create enough of a graph to test, 3 layers two grandhild collections should be sufficient:
WO
WOITEMS
WOITEMLABORS
WOITEMPARTS
CREATE (POST):
CreateFromxxxx routes (NO TEST REQUIRED) CreateFromxxxx routes (NO TEST REQUIRED)
POST accepts workorder full graph (test) POST accepts NEW 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? RETRIEVE (GET):
Get(id) - simple get, just confirm entire graph comes across
GetByRelative(ayatype, id) (no test required)
UPDATE (PATCH): 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) 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 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) woitem 1 (OP flag ="update", all fields as in a "put" operation, nothing left out, assumed all are changed)
@@ -145,6 +156,9 @@ todo: PLANNING WORKORDER considerations:
Server accepts graph at single WO POST route (since it's not a put) Server accepts graph at single WO POST route (since it's not a put)
UI UI
ui manufactures the return object with the OP fields by doing dirty tracking on changes ui manufactures the return object with the OP fields by doing dirty tracking on changes
DELETE
Not much here except handling delete will be more intensive and sophisticated when have real data but for now if the graph deletes then that's enough
Test how to delete graph without ref. integrity errors
UI UI