ayanova/devdocs/todo.txt

@@ -70,12 +70,11 @@ CURRENT TODOs
 @@@@@@@@@@@ ROADMAP STAGE 2:
 
 CURRENT ITEM:
-	BIZ OBJECT STUBBING FOR EXPORT TESTING OF HUGE ATTACHMENTS AND WIKI AND ATTACHED DOCS
-
+	
 TEST: Proposed workorder structure and routes
-	See below PROPOSAL section
-
+	See below PROPOSAL section, implement "tons of routes" test option with minimal objects detailed and then update the Export v8 code to work with it once some basic tests confirm how it will work
 
+BIZ OBJECT STUBBING FOR EXPORT TESTING OF HUGE ATTACHMENTS AND WIKI AND ATTACHED DOCS
 TEST EXPORT BIG DATABASE WITH TONS OF ATTACHMENTS
 
 Finish off the v8 test export then get the below shit done so can move to stage 3 ASAP
@@ -87,6 +86,84 @@ Finish off the v8 test export then get the below shit done so can move to stage
 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?)
+			still no idea after lot's of planning, answer is probably not needed at all
+
+		How can I avoid concurrency issues?
+			concurrency check each record in graph, not entire workorder from top
+
+		How to minimize data sent, make fast saves?
+			I'm leaning towards the tons of routes option, need to test it out
+
+			PATCH, send all changes in graph in one go
+				most efficient, sends all changes in one go
+				if any part fails it all fails
+				requires second copy of wo for diffing
+				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)
+						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)
+					issues with patch:
+						how to post a whole object leaving blank when so many fields will be required?
+							maybe we don't make them required at the object field annotation level but only at the db level and as a biz rule?
+						how to synchronize objects and id's?
+							i.e. reverse patch back again
+							for example, you add two woitems, save, you have two now that are not id'd and don't know which is which
+								server has to return something identifying which is which and assigned ID, plus it might add data back or change data due to rules or whatever
+							Maybe server sends back entire saved objects?
+				issues:
+					how to update client end with update back from server when saved (server will add id and may change fields or even add things)
+
+			* TONS OF ROUTES: Update individual portions as seperate objects to their own routes sequentially
+				i.e. client determines what's different, only sends an update for each object to it's own route
+				requires second copy of wo for diffing
+				goes over workorder, looks for changes, sends update for each object individually and patches up local from result
+				so if a workorderitempart has changed then it sends only that for update individually
+				Example routes:
+				Post: Workorder/1/WorkorderItem/2/Labor/4 {updated object}
+				WorkOrder/{woid} <-entire workorder, get for all, post for entire, put to update entire (not likely to use but?)
+				WorkOrder/{woid}/WorkorderItems <- all workorderitems, post to add new, put to update all as a collection
+				WorkOrder/{woid}/WorkOrderItems/{woitemid} <- CRUD single woitemid
+				WorkOrder/{woid}/WorkOrderItems/{woitemid}/Labors <- entire labor collection CRUD ops over all collection (also ADD new labor here (POST))
+				WorkOrder/{woid}/WorkOrderItems/{woitemid}/Labors/{laborid} <- Crud on individual item
+
+				This way is pretty solid, will result in a lot of routes but a lot of the code can be shared in the biz object, so for example if updating a labor or a collection of labor most code the same
+				Efficiency:
+					Since there is a route for every bit of the workorder the client can pick how high up to update based on diff check
+					so if only one single bit of a header has changed then only update that bit (or will it need the collection to not remove it? No because collection route is where you remove an item)
+					or if only a deeply nested labor has changed, just PUTS it to that exact route and udpates concurrency token on result
+				since the workorder is not really influenced as  a whole by updates to portions this could work and be a bit less problematic than JSONPATCH which really seems to be a bit of a stretch
+
+
+NOTE: can put part of the route in the controller, so for example if every route in that controller needs to identify a workorder then this kind of thing is possible, not sure if helpful or not yet:
+[Route("api/campus/{campusId:int}/building")]
+public class BuildingController : Controller {
+    //...
+
+    [HttpGet]
+    [Route("{buildingId:int}")] // Matches GET api/campus/123/building/456
+    public IActionResult GetBuilding ([FromRoute]int campusId, [FromRoute]int buildingId) { 
+        //... validate campus id along with building id 
+    }    
+}
+				
+				issues: 
+					very chatty, could be slow
+
+			PUT, update entire workorder on every save		
+				Very easy to code, basically send it all and see what happens
+				Very clean, no need to worry about bits and pieces being tracked etc
+				issues: 
+					not very efficient, needs to send entire graph on every save even if user just changed one character
+
+
+		How to support undo?
+		How to show what's dirty on form?
+
+		
 
 	BUSINESS RULES (v7)
 		In reality there are almost no business rules in v7 workorder graph.  
@@ -144,18 +221,9 @@ todo: PLANNING WORKORDER considerations:
 					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)
-						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)
-					issues with patch:
-						how to post a whole object leaving blank when so many fields will be required?
-						maybe we don't make them required at the object field annotation level but only at the db level and as a biz rule?
-						
+				UPDATE (PUT?)
+					Test code tons of routes method detailed above
+
 					SERVER
 						Server accepts graph at single WO POST route (since it's not a put)
 					UI