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,6 +175,10 @@ 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.
+