Service - Addresses

From Izara Wiki
Revision as of 12:21, 9 February 2022 by Sven the Barbarian (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Overview

Addresses linking to LocationIds, including optional address templates.

Repository

https://bitbucket.org/izara-core-locations/izara-core-addresses-addresses/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"
}

AddressTemplates

{
	rootlocationNodeId: "xx",
	addressTemplateTag: "xx", // user defined string
	templateElements: [ // use Dynamo List as want to preserve order of elements
		"customText",
		"newLine",
		"customText",
		"newLine",
		23,
		"newLine",
		6988,
		"space",
		"6465",
		"newLine",
		"rootlocationNodeId",
	]
}
  • partition key: rootlocationNodeId
  • sort key: addressTemplateTag
  • templateElements point to locationType nodes

Graph database

Service - Locations Graph

Nodes

{ 
	nodeLabel: "{AddressesSharedLib.ADDRESS_GRAPH_NODE_LABEL}", // "address"
	schema: {
		immutable: true,
		restrictProperties: true,
		restrictRelationships: true,
		properties: {
			addressId: {
				identifier: true, // create unique id from request details including uniqueMessageId
			},
			addressTag: {}, // free text name given by user
			addressText: {), // full text of the address, ready to be used by service
			rootlocationNodeId: {}, // optional, if created from addressTemplate
			addressTemplateTag: {}, // optional, if created from addressTemplate
			templateElements: {}, // optional, if not created from addressTemplate, is the structure submitted for the address, same format as addressTemplate templateElements
			addressElements: {}, // the values used in each configurable templateElement
			languageId: {}, will determine the translation used by each locationTypeId
		},
	}
}

Relationships

{
	relationshipType: "{AddressesSharedLib.HasAddressRelType()}", // "has_address"
	schema: {
		elementCanBeRemoved: true,
		allPropertiesImmutable: true,
		restrictProperties: true,
		properties: {
			originTimestamp: //timestamp the request to create/change this relationship was sent
		},
	}
}
{
	relationshipType: "{AddressesSharedLib.DisabledAddressRelType()}", // "disabled_address"
	schema: {
		elementCanBeRemoved: true,
		allPropertiesImmutable: true,
		restrictProperties: true,
		properties: {
			originTimestamp: //timestamp the request to create/change this relationship was sent
		},
	}
}
{
	relationshipType: "{AddressesSharedLib.defaultAddressRelType()}", // "default_address"
	schema: {
		elementCanBeRemoved: true,
		allPropertiesImmutable: true,
		restrictProperties: true,
		properties: {
			originTimestamp: //timestamp the request to create/change this relationship was sent
		},
	}
}
{
	relationshipType: "{AddressesSharedLib.addressHasLocationNodeRelType()}", // "addressHas_LocationNode"
	schema: {
		elementCanBeRemoved: false,
		allPropertiesImmutable: true,
		restrictProperties: true,
		properties: {
			originTimestamp: //timestamp the request to create/change this relationship was sent
			order: 1 // the order within the template/addressText where this locationNode is
		},
	}
}

Notes

  • storing the addressText directly into the address node means the address text is fixed and will not be adjusted by for example translation changes in locationNodes
  • addressText is already translated and stores it's languageId, so no confusion when viewing an address what parts are what language (eg customText elements are fixed text but locationNodeIds could change if their translated text is calculated on the fly)

Working documents

Addresses