Service - Locations

Overview

Manages Location Graph

Repository

https://bitbucket.org/izara-core-locations/izara-core-locations-locations/src/master/

DynamoDB tables

Standard Config Table Per Service

Configuration tags

{
	configKey: "LocationsGraphServiceName"
	configTag: "LocationsGraphServiceName"
	configValue: xxx // eg: "Locations"
}

{
	configKey: "TranslationGraphServiceName"
	configTag: "TranslationGraphServiceName"
	configValue: xxx // eg: "TranslationGraph"
}

Graph database

Service - Locations Graph

Nodes

{
	nodeLabel: "{LocationsSharedLib.LOCATIONNODE_GRAPH_NODE_LABEL}", // "locationNode"
	schema: {
		identifier: true,
		restrictProperties: true,
		restrictRelationships: true,
		properties: {
			locationNodeId: {
				identifier: true, // create unique id from translation and uniqueMessageId (because multiple locationNode can have same translation)
			},
		},
	}
}

{
	nodeLabel: "{LocationsSharedLib.LOCATIONTYPE_GRAPH_NODE_LABEL}", // "locationType"
	schema: {
		identifier: true,
		restrictProperties: true,
		restrictRelationships: true,
		properties: {
			locationTypeId: {
				identifier: true, // create unique id from translation
			},
		},
	}
}

• Want to split eg postcodes for different countries into their own locationTypes, this will mean each has to have a different translation (two cannot be named "Post Code" or they will be considered the same label/use the same locationType node), for now use unique translations for each, but could add another translation as the presentation text, which is not used to identify the type, but when presenting the value

{
	nodeLabel: "{LocationsSharedLib.LOCATIONLINK_GRAPH_NODE_LABEL}", // "locationLink"
	schema: {
		identifier: true,
		restrictProperties: true,
		restrictRelationships: true,
		properties: {
			locationLinkId: {
				identifier: true, // create unique id from parent and child locationNode identifiers, because we only want one link to exist between two specific nodes
			},
		},
	}
}

Relationships

{
	relationshipType: "{LocationsSharedLib.HAS_LOCATIONLINK_GRAPH_REL_TYPE}", // "has_locationLink
	schema: {
		elementCanBeRemoved: false,
		allPropertiesImmutable: true,
		restrictProperties: true,
		properties: {
		},
	}
}

{
	relationshipType: "{LocationsSharedLib.IS_LOCATIONNODE_GRAPH_REL_TYPE}", // "is_locationNode
	schema: {
		elementCanBeRemoved: false,
		allPropertiesImmutable: true,
		restrictProperties: true,
		properties: {
		},
	}
}

{
	relationshipType: "{LocationsSharedLib.IS_LOCATIONTYPE_GRAPH_REL_TYPE}", // "is_locationType
	schema: {
		elementCanBeRemoved: false,
		allPropertiesImmutable: true,
		restrictProperties: true,
		properties: {
		},
	}
}

Basic node schemas

{
	nodeLabel: "{LocationsSharedLib.LOCATIONNODE_GRAPH_NODE_LABEL}",
	schema: {
		identifier: true,
		restrictProperties: true,
		restrictRelationships: true,
		properties: {
			locationNodeId: {
				identifier: true,
			},
		},
	}
}

{
	nodeLabel: "{LocationsSharedLib.LOCATIONTYPE_GRAPH_NODE_LABEL}",
	schema: {
		identifier: true,
		restrictProperties: true,
		restrictRelationships: true,
		properties: {
			locationTypeId: {
				identifier: true,
			},
		},
	}
}

Translations

locationNode

• given name of the location, eg: Bangkok

locationType

• description of the type of label, eg: Country
• see note about about adding a second translation textTag for presentation text, because locationType translation is used to create locationTypeId, so if want to split Post Codes for different countries into their own locationTypes will need to have unique text (eg: "Post Code (USA)", but might want to present with same text (eg: "Post Code")

Using locationNodeIds to search for sell offers

• Sellers set where they ship to, setting more inclusive ship to locationNodeIds is best (if it matches their actual service) because will be included in all searches for lower level locationNodeIds
• Buyers set where they are so can see sell offers that ship there, best to be as low level/specific as possible because will search sell offers for all matching parents
• Buyers can use their address which will find all parent locationNodeIds for all locationNodeIds in their address, or buyers can choose specific locationNodeId/s, eg a country when not signed in, this would return less results as will only return sell offers that specify they can ship anywhere in that country

Possible optimization when finding matching parents

• eg: when given a set of locationNodeIds from a buyer's address, we find all parent locationNodeIds and use this list to filter ship to locationNodeIds to find sell offers that ship to this buyer. This can result in a large number of queries
• this will be mitigated a lot by our cached complex filter and search results, but is still a lot of processing
• in all cases, all nodes set in an address would be searched for, these optimizations are for finding additional parents for checking
• we could reduce the filtering work by reducing the number of parent locationNodeIds
• one way is to only accept parent links that meet a certain weight, eg reach a limit of how many times they have been used as a parent in user addresses. Problem with this is lower level links will have less links, and just because a link is used little does not make it invalid
• another way is to curate the types of parent links to search for, eg only accept certain chains of links, such as city > post code > state, any parent nodes that do not match this chain are ignored. Would probably need to know the country beforehand to set the accepted chains. Additional processing to handle this might outweigh the gains
• another is to have curated parents, user entry (eg by a low level admin role) sets which are real links worth checking

Working documents

Locations