devdocs/specs/core-tags.txt

@@ -89,33 +89,4 @@ TAG GROUP DEPRECATED 2018-12-05
                 In this way the filters are always dynamically linked to the tags in the group and reflect the most recent changes to the group
                 tl/dr: don't store the tag id's from a group in the filter, store the group id separately and build the list on query
 
-                
-DEPRECATED 2018-12-05 SCHEMA
-This is outdated, going with an array in table solution instead, much better than this concept
-=-=-=-
-            4 tables:
-
-            TAGS
-                - name text not null lowercase only
-                - id bigserial
-                - OwnerId
-            
-            TAGMAP
-                - ObjectId
-                - ObjectType
-                - TagId
-
-            TAGGROUP
-                - name text not null lowercase only
-                - id bigserial
-                - OwnerId
-
-            TAGGROUPMAP
-                - TagGroupId   
-                - TagId   
-                
-            INDEXES
-                - Initial index is on the name of the tag as that will be searched for??
-                - After some research I think it's best to just make it, populate it with a great deal of test data and then test query it and see what indexes give the best performance
-                
-
+ 

devdocs/todo.txt

@@ -39,6 +39,7 @@ Do the stuff in the Client todo first then back to the server as required.
 
 DO CLIENT STUFF NOW COME BACK TO THIS STUFF LATER
 
+###*** BEFORE NEXT UPDATE TO DEVOPS SERVER:::::::
 TODO: Make it fucking easier to test deploy and erase db and fetch key and all that shit
 	- I would like to deploy, bring it up and then from a simple command from the api explorer trigger all the above
 	- OR, ding ding ding ding...FUCKING CODE THE CLIENT SIDE FOR OPS SHIT LIKE FETCHING KEY, ERASING DB ETC!!!!