Service - Category Tree Standard

Overview

Handler service for the standard category tree type.

Repository

https://bitbucket.org/stb_working/category-tree-standard/src/master/

DynamoDB tables

Standard Config Table Per Service

Configuration tags

{
	configTag: "defaultValue"
	configKey: "locationTreeAreaNodeId"
	configValue: {eg: id for USA, or international?}
}

{
	configTag: "defaultValue"
	configKey: "browseQuantity"
	configValue: {eg: 1}
}

Neptune graph database

CategoryTree

• Structure allows for one category to be found at the same level of the graph (same parent) multiple times, but eg with different filter
• Structure keeps a record of all changes, so can be rolled back eg if a user makes changes incorrectly

Vertex labels

catalog

• to create an origin node per catalog that top level categories are children of
• vertexId: catalog_{catalogId}
• is never edited or removed from the graph

categoryTreeNode

• represents one parent-child relationship in the graph
• vertexId: random uuid?
• is never edited or removed from the graph

properties

catalogId (maybe not needed but more efficient if have?)

categoryId

categoryTreeNodeSettings

• holds the editable settings for a categoryTreeNode
• vertexId: random uuid
• is never edited or removed from the graph
• when settings are changed a new vertex is created, the edge has a property with the timestamp when setting created
• the hasSettings edge's timestamp is used to find the current settings
• we can find who created the categoryTreeNodeSettings (and thus disabled the previous settings) by looking at the categoryTreeNodeSettings createdByUserId edge

categoryTreeNodeSettings vertex properties

filter

full filter for this node, will often match catalog's default filter unless specifically set not to

requiredData

searchType

sellOffer|product|variantProduct

filterMatchParent

bool

defaults to true, if true will be updated to always match this node's parent node, if false must manually update

requiredDataMatchCatalog

bool

defaults to true, if true will be updated to always match the catalog's filter, if false must manually update

searchTypeMatchCatalog

bool

if set to true then will update when catalog searchType changes

user

• one userId
• vertexId: user_{userId}
• is never edited or removed from the graph

Edge labels

hasChild

• creates a link between two categoryTreeNode vertices or catalog > categoryTreeNode vertices
• edge can enabled or disabled, otherwise is never edited or removed from the graph
• edgeId: {timestamp created}_{subject vertexId}_hasChild_{object vertexId}

properties

disabled

boolean

hasSettings

• creates a link between categoryTreeNode and categoryTreeNodeSettings
• is never edited or removed from the graph

properties

timestamp

time the settings were added

createdByUserId

• creates a link between categoryTreeNodeSettings > user vertex or categoryTreeNode > user vertex

disabledBy

• creates a link between categoryTreeNode > user vertex
• each time a categoryTreeNode is disabled or enabled a new edge is created linking the userId and saving the date, so have record of changes

properties

timestamp

time the categoryTreeNode was disabled

enabledBy

• creates a link between categoryTreeNode > user vertex
• each time a categoryTreeNode is disabled or enabled a new edge is created linking the userId and saving the date, so have record of changes

properties

timestamp

time the categoryTreeNode was enabled

All child category results should show in a parents results

• A child category might include products that are not part of a parent category, but when browsing the parent category we want to show all results that return for child categories.
• We can do this by accumulating all child filters into the parents filter.
• If all children share the same catalog default filter this is not too difficult, we add an or filter that includes all child categoryId's.
• If some children have custom filters we will need to separate them out as a separate or filter that groups that child's categoryId with it's filter
• I believe processing these large filters can still be efficient because hash of filter exists for the full (or any partial) filter and we cache results for each part of the filter.

How filter is calculated

• In most cases all categoryTreeNodes will share the same filter as the catalog's filter
• Each categoryTreeNode maintains it's own copy of the filter so can be easily pulled when browsing
• Each categoryTreeNode can overwrite this setting and maintain its own independent filter
• If a category sets it's own filter it will likely add to the default filter to maintain a standard experience for the user, but this is not required, up to the user

Initial filter settings

• When creating a new categoryTreeNode for a catalog the filter for the node can be set, if it is empty inherit the filter from the parent categoryTreeNode. If is a top level node it inherits the catalog's filter
• if filterMatchCatalog is set to true this will overwrite the filter setting and the catalog
• Not sure how to handle updating catalog's (default) filter, perhaps have a bool in the categoryTreeNode that sets whether it's filter should track and update when catalog filter updates.

How requiredData is calculated

• In most cases all categoryTreeNodes will share the same filter and requiredData, matching the catalog's filter and this service's default requiredData, but allow for each categoryTreeNode to set its own. When this happens it will likely add to the default filter, to maintain a standard experience for the user.
• When creating a new categoryTreeNode for a catalog the requiredData and filter for the node can be set, if not set the default is to inherit from that node's parent categoryTreeNode. If is a top level node it inherits from the catalog's (default) filter.
• Not sure how to handle updating catalog's (default) filter, perhaps have a bool in the categoryTreeNode that sets whether it's filter should track and update when catalog filter updates.

Adding client submitted filter

• Would get added as an and grouped filter.

Top level results

• Each catalog has a top level record saved into CategoryTreeNode table, categoryId = 0, this will be a combination of catalog filter, and all child categoryIds

Ideas

• This service could hold a list of Products for each category and do things like record popularity etc.. partial lists would be OK, anything we want to add. For features like popularity might not want to remove products when they no longer match the catagory, might want to maintain their details in case get added again. This type of idea might be served through the graph database.
• Our current structure allows one category to have multiple parents, that child category will have the same settings no matter what path you travel through the tree to reach it. Not sure how to handle presentation of the parent category/location for any category, maybe most popular, or simply first found?

Working documents

Category Tree Standard