2024-11-17 - ComplexFilter traversal filterElement

From Izara Wiki
Jump to navigation Jump to search

Service - Complex Filter

Overview

Add filter element in Complex Filter service that allows for deep path searching in graph relationships.

Examples

Find all parent locationNodes for locationNode/s

Idea

New filter element names 'traversal' that follows a similar format to a deepPathSearch request but in reverse order.

Reverse order because in the complex filter request the top level complex filter is the result of the deep path search, so the traversal request object will start with the final deep path step.

Each traversal filter element object can set an array of objTypes and relTypes+direction (links?), and how many hops, perhaps limit result count as well.

Example 1

  • Find all SellOfferPlan identifiers that link to a product identifiers

Traversal filter element object:

  • ComplexFilter request objType sellOfferPlan, it has a traversal filterElement that has 2 steps
  • First step objType SellOffer, relType hasSellOfferPlan, direction sellOfferPlan>SellOffer, hops 1
  • Second step objType Product, relType hasSellOffer, direction SellOffer>Product, hops 1, obj property search is product identifier

DeepPathSearch request object:

  • Initial step objType Product, node property filter is product identifier
  • First step objType SellOffer, relType hasSellOffer, relType Product>SellOffer, hops 1
  • Second step objType sellOfferPlan, relType hasSellOfferPlan, direction SellOffer>sellOfferPlan, hops 1

Example 2

  • Find all parent locationNodes for a locationNode, needs to traverse many hops across 2 relationships (child)locationNode > locationLink > (parent)locationNode
  • Wants to return every parent locationNode id, not just leaf results

Traversal filter element object:

  • ComplexFilter request objType (parent)locationNode, it has a traversal filterElement that has 1 step
  • objTypes [locationNode, locationLink], relTypes [has_locationLink, is_locationNode], direction (child)locationNode > locationLink > (parent)locationNode, hops (traversal limit), obj property search is locationNode identifier

DeepPathSearch request object:

  • Initial step objType locationNode, node property filter is locationNode identifier
  • First step objTypes [locationNode, locationLink], relTypes [has_locationLink, is_locationNode], direction (child)locationNode > locationLink > (parent)locationNode, hops (traversal limit)

Logic flow

We could have an endpoint in external service to handle each traversal element but I think not necessary because the conversion to deepPathSearch request is standard, can put the flow and awaitingStep into ComplexFilter service.

Might want to wrap DeepPathSearch logic in a way that allows for scale, this would mean paginating results of deepPathSearch and either saving them into a storedCache DynamoDB table in GraphHandler, or GraphHandler saving to an external service's DynamoDB table.

Future idea

  • Add filter to each objType in objTypes, eg only pass locationLinks that are of an allowable 'weight'
  • Order by 'weight' and add record count limit to returned results. This might be handled better as sortResult, pass all locationLinks to SortResult service, sort by weight and perform comparison.