From 41e435d1b4f3fd32e61f7868ea4263502de30f9a Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Wed, 6 May 2020 20:27:47 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 68 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 66 insertions(+), 2 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 33765916..fbab4777 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -83,11 +83,71 @@ Finish off the v8 test export then get the below shit done so can move to stage -todo: PLANNING workorder data and class and route structure: +todo: PLANNING WORKORDER considerations: + + DEPENDENCIES + Workorder is not dependent on it's children for anything + WoItem is not dependent on any of it's children + In fact nothing in any part of the wo is dependent on anything else during normal ops + + CONCURRENCY + If the client updates part of the wo graph, only that exact record really needs dependency checking. + There *is* however business rules that might take hold but that's all at the server and not related to concurrency directly + For example, on any change to the wo graph the server has to see if the wo is still editable and hasn't been locked or user's rights changed + But that's not strictly concurrency related in teh sense that another user change the *same* record being updated + So, for v8 as long as it can handle a portional update to part of the graph and uses the concurrency of that exact record to check then it sidesteps a lot of multi-user scenarios + This was only an issue in v7 due to it using only the wo header itself as the source of concurrency checking which would *always* involve the whole graph in any change anywhere + + for example: + WOHEADER (concurrency id, dirty flag at client) + WOITEM (concurrency id, dirty flag at client) + woitempart (concurrencyid dirty flag at client) + woitemlabor (concurrencyid, dirty flag at client) + WOITEM (concurrency id, dirty flag at client) + woitemscheduser (own concurrency, dirty flag etc) + woitempart (concurrencyid dirty flag at client) + woitemlabor (concurrencyid, dirty flag at client) + + ROUTES + In light of dependencies and concurrency it is ideal if the server can handle updates to any portion of the graph independently + But, do we really want CRUD routes for every descendent of the workorder graph? (maybe, just not sure) + + + + 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? + + + 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? + 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) + woitem2 (OP flag="no OP", just a placeholder for children with changes) + labor 2 (OP flag = "update" with all data) + labor 3 (OP flag="delete" with concurrency token and nothing else) + labor 4 (OP flag="Add", with all PUT data) + + + UI + Ideally I would like to only send the bits that are altered to save bandwidth + A biz object for each one? probably need the parent for biz rules and shit so likely best to keep in one file Controller - all in root controller or seperate controllers? likely follows biz object decision + case 1714 re-rises the question about concurrency and mutiple editors of a workorder + Look into how independent changes can be from each other, i.e. is it safe to have two users editing two different woitems on a workorder? + This might make people happier. + Like, what exactly affects what else on a workorder. Do you save the whole wo to the route at once even though you just added a woitem or..? + If I code it to send the whole wo on a change to even a grandchild then that's heavy traffic for a minor change + - actually no, it's not really that heavy, even a fairly fat workorder will be way under 100kb, most probably under 1kb + should really only send the minimum data required to fulfil the change. + Maybe need two copies of wo at client so can tell what has changed and then only send that bit. + But then need routes to handle that? + Or can the wo route just accept a blank header with items hanging off it that have changed only? (like a patch?) + Use foreign keys!! Consider UI in this as well, will need to decide at least what is visible when Workorder UI good ideas here: https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3475 @@ -115,7 +175,11 @@ todo: PLANNING workorder data and class and route structure: plus, I'm thinking it opens door to textual scheme like appending -A or whatever to a wo. or, is that a display issue? Calling something "serial" implies it's unique but it isn't, maybe I should call it "number" instead or "ID" or something? - + INFO: did a test workorder with ALL fields filled out heavily and one woitem, exported from db entire graph based on detailed report so every line was every item repeated + still only 84kb and it's a lot bigger than any typical wo in v8 would be as it will be far more efficient without having to repeat lines flatly + so I think size of object is a non-issue really from a practical standpoint. + + ---------------------------------------------