devdocs/specs/core-list-graph-datatable-filtering-paging.txt

@@ -63,12 +63,15 @@ NOTES ABOUT WHY I DID THE FILTEROPTIONS LIKE I DID:
 
 LIST FILTERING TODO
     - DONE test for fetching widget filter options (localized, so have two users test each for expected response)
-    - Add test for excercising all of DataFilterController route including rights to non personal alternative owner etc
-    - Add test for correctly validated Widget datafilter when saved or updated via datafiltercontroller (sanity check of the filter settings and options IFilterableObject implemented)
+    - DONE test for excercising all of DataFilterController route including rights to non personal alternative owner etc
+    - DONE test for correctly validated Widget datafilter when saved or updated via datafiltercontroller (sanity check of the filter settings and options IFilterableObject implemented)
+
+    - DONE Add test for providing saved filter id to widgetlist and recieving correct filtered / paged / sorted results (test all those)
+        - Requires filter to sql code to be written and changes to the widgetlist route
+    
+Add TAGS test for providing saved filter id to widgetlist WITH TAGS specified and recieving correct filtered / paged / sorted results (test all those)
+    - Requires TAGS filter code to be written and changes to the widgetlist route
 
-Add test for providing saved filter id to widgetlist and recieving correct filtered / paged / sorted results (test all those)
-    - Requires filter to sql code to be written and changes to the widgetlist route
-  
 - Client side
   - Implement filter editor dialog and test
 

devdocs/specs/core-tags.txt

@@ -2,21 +2,16 @@
 
 Main case is 3373 https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3373
 
-TAG-GROUP - bag of tags
-    Modify the below and coded and tests and tables to now have feature for tag groups
-    They will be in their own table with a dictionary table of tag ids and tag group id's to link
-    They are used for read purposes, you never tag an item with a tag group, only query by group.
-    If a group is deleted tags it contains are NOT deleted or changed
-    If a tag is deleted it must be removed from any tag groups and if there are no other items in that tag group then the tag group must be deleted as well??
-        - Or maybe is just an empty group with a warning symbol in ui
-    Tag groups will become a major way to save filters for things because a lot of filtering will be by tags so this should be a solid feature.
-    - RETRIEVAL / PICKLISTS: need to modify the tag picklist to optionally return TAGGROUP names as well as identify they are group so UI can feature differently
 
-    FILTERING AND SORTING BY TAG-GROUP
-        - All code that filters and sorts by tag should accept a tag group as a separate type of input and dynamically build the tag filter list from the group and individual tags separately
-         rather than storing a list of tags at the moment a group is applied.  
-         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
+RESEARCH:
+https://www.databasesoup.com/2015/01/tag-all-things.html
+https://www.npgsql.org/efcore/mapping/array.html
+https://www.postgresql.org/docs/current/arrays.html
+
+2018-12-05 Research showed that actually I'm doing tags all wrong and the multi table method is not correct performance wise or simplicity wise
+The winning method in a test using postgres was a text array of tags with a "gin" index see databasesoup link above.
+
+
 
 FORMAT
 =-=-=-
@@ -28,35 +23,7 @@ tags ...
     always converts to lower invariant culture
     - (probably not this, utf-8 ok: must use the ascii character set a-z 0-9 + # - .)
 
-
 SCHEMA
-=-=-=-
-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
-    
-
 
 USE-CASES
 Add a tag to an object type and id, start typing and a selection list fills in to select from
@@ -99,4 +66,55 @@ V7IMPORT
 See case 3373 for a list of things that will become tags
 
 
+OLD DEPRECATED STUFF BELOW HERE
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+
+TAG GROUP DEPRECATED 2018-12-05 
+    I'm deprecating this as it's surplus to requirements: users will be able to specify multiple tags in a filter and they can save filters so no need for bags of tags
+
+            TAG-GROUP - bag of tags
+            Modify the below and coded and tests and tables to now have feature for tag groups
+            They will be in their own table with a dictionary table of tag ids and tag group id's to link
+            They are used for read purposes, you never tag an item with a tag group, only query by group.
+            If a group is deleted tags it contains are NOT deleted or changed
+            If a tag is deleted it must be removed from any tag groups and if there are no other items in that tag group then the tag group must be deleted as well??
+                - Or maybe is just an empty group with a warning symbol in ui
+            Tag groups will become a major way to save filters for things because a lot of filtering will be by tags so this should be a solid feature.
+            - RETRIEVAL / PICKLISTS: need to modify the tag picklist to optionally return TAGGROUP names as well as identify they are group so UI can feature differently
+
+            FILTERING AND SORTING BY TAG-GROUP
+                - All code that filters and sorts by tag should accept a tag group as a separate type of input and dynamically build the tag filter list from the group and individual tags separately
+                rather than storing a list of tags at the moment a group is applied.  
+                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

@@ -17,6 +17,18 @@ SERVER ALL LIST ROUTES
 	- See widgetBiz getmany method for example
 	- This applies to all picklist and list routes
 
+
+
+DEVOPS - PUT UP A DEVOPS COPY AFTER THE ABOVE IS DONE AND RUN ALL UNIT TESTS TO CONFIRM DATE FILTER COD
+
+
+
+
+
+
+
+
+
 INITIAL TESTING NOTES:
 	- Tested on iPad (safari, chrome), Pixel (chrome), samsung chrome and samsung browser, desktop chrome, firefox browsers, android table (looks good, works but very slow, good for testing)
 		- Looks essentially identical on each!!!!