Izara Wiki - Recent changes [en]

Per Service Schemas

Sven the Barbarian — Tue, 25 Aug 2026 14:07:23 GMT

@@ Line 475: / Line 475: @@
 </syntaxhighlight>
-= Generated S3 files =
+= Error Schema =
 * generate multiple files for different uses, eg:

Standard Data Structures

Sven the Barbarian — Tue, 25 Aug 2026 14:04:07 GMT

← Older revision		Revision as of 14:04, 25 August 2026
Line 302:		Line 302:
	* identifiers: contains identifiers data		* identifiers: contains identifiers data
	* fields: another data except		* fields: another data except

			== errorType ==

			<syntaxhighlight lang="JavaScript">
			{
			serviceTag: "xxx",
			errorTag: "yyy"
			}
			</syntaxhighlight>

	== example data ==		== example data ==

User Data Handling

Sven the Barbarian — Tue, 25 Aug 2026 13:49:32 GMT

← Older revision		Revision as of 13:49, 25 August 2026
Line 55:		Line 55:
	== Object level Account Limits ==		== Object level Account Limits ==

	== Add increase/decrease ~~action~~ =		== Generating code ==

			* Can generate AccountLimit tags automatically for each flow
			* if flow objType has belongTo or rbac addOnDataStructure always check AccountLimit, eg createOrder number of orders allowed to create
			* some flows accept multiple objType, eg createObject, if only generated flows are like this then we could hardcode request to AccountLimit from objType param, but if developer made flows also are like this we could add a setting to the flow, eg: multipleObjTypes = true, if true then could standardize param name and generate request to AccountLimit
			* if flow is event S3 can generate AccountLimit request for size of file

			== Add increase/decrease effect ==

	* currently account limits will find the highest limit of all roles attached to a customer		* currently account limits will find the highest limit of all roles attached to a customer

Per Service Schemas

Seagame — Tue, 25 Aug 2026 02:44:14 GMT

ObjectSchema | ObjectFieldSchema.js

← Older revision		Revision as of 02:44, 25 August 2026
(One intermediate revision by the same user not shown)
Line 62:		Line 62:
	},		},
	{		{
	type:"rbac"		type:"rbac",
			billalble:true // true \|\| false , required
	},		},
	// ...		// ...

User Data Handling

Sven the Barbarian — Sun, 23 Aug 2026 10:24:31 GMT

Show changes

Per Service Schemas

Sven the Barbarian — Sun, 23 Aug 2026 09:54:16 GMT

← Older revision		Revision as of 09:54, 23 August 2026
Line 24:		Line 24:
	// systemGenerated must be created by flow/s		// systemGenerated must be created by flow/s
	// searchResultGenerated see separate notes below		// searchResultGenerated see separate notes below
	generatedBy: "~~userGenerated~~" \|\| "~~systemGenerated~~" \|\| "systemNoUserId" \|\| "systemWithUserId" \|\| "searchResultGenerated" // required		generatedBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"\|"searchResultGenerated" // required
	searchResultGeneratedFlowType: {}, // for generatedBy = searchResultGenerated		searchResultGeneratedFlowType: {}, // for generatedBy = searchResultGenerated
	addOnDataStructure: [ // optional, add for additional setting to objectType		addOnDataStructure: [ // optional, add for additional setting to objectType
Line 195:		Line 195:
	{		{
	"xxx": { // relationshipTag - name of relationship type stored in graph		"xxx": { // relationshipTag - name of relationship type stored in graph
	generatedBy: "~~userGenerated~~" \|\| "~~systemGenerated~~" \|\| "systemNoUserId" \|\| "systemWithUserId~~" // default="userGenerated~~"		generatedBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"
	canChangeToRelTypes: [		canChangeToRelTypes: [
	{		{
Line 202:		Line 202:
	relationshipTag: "yyy"		relationshipTag: "yyy"
	},		},
	changeBy: "~~user~~" // "~~systemNoUserId~~" \| "~~systemWithUserId~~" \| "~~user", default="user~~"		changeBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"
	}		}
	// another relType		// another relType
Line 225:		Line 225:
	requiredOnCreate: false, // default=false		requiredOnCreate: false, // default=false
	optionalOnCreate: false, // default = false		optionalOnCreate: false, // default = false
	updateBy: "~~user~~" // "~~systemNoUserId~~" \| "~~systemWithUserId~~" \| "~~user~~" \| "none~~", default="user~~"		updateBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"\|"none"
	validation: {} // ajv syntax		validation: {} // ajv syntax
	},		},
Line 241:		Line 241:
	requiredOnCreate: true, // if set true will create relationshipTag when create objType data, if both "from" and "to" linkType="many" should not have requiredOnCreate, exists in "from" or "to" only		requiredOnCreate: true, // if set true will create relationshipTag when create objType data, if both "from" and "to" linkType="many" should not have requiredOnCreate, exists in "from" or "to" only
	linkType: "", // one \| many		linkType: "", // one \| many
	// moveBy: "~~none~~", // "~~systemNoUserId~~" \| "~~systemWithUserId~~" \| "~~user~~" \| ~~"none", default=~~"none"		// moveBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"\|"none"
	// belongTo:true		// belongTo:true
	},		},
Line 251:		Line 251:
	linkType: "", // one \| many		linkType: "", // one \| many
	// moveBy allows the relationship to be moved between 2 instances of the same objType only		// moveBy allows the relationship to be moved between 2 instances of the same objType only
	moveBy: "~~none~~", // "~~systemNoUserId~~" \| "~~systemWithUserId~~" \| "~~user~~" \| ~~"none", default=~~"none"		moveBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"\|"none"
	belongTo:true, // false		belongTo:true, // false
	},		},
Line 295:		Line 295:
	{		{
	flowTag: "yyy",		flowTag: "yyy",
	initiateBy: "~~user~~", // "user" \| "~~system~~" ~~-- if receive plugin should be user~~		initiateBy: "xx", // "user"\|"systemNoUserId"\|"systemWithUserId"
	handleObj: "one", // "one" \| "multi"		handleObj: "one", // "one" \| "multi"
	statusType: "statusField", // "statusField" \| "storedCache" \| "none" \| "triggerCache"		statusType: "statusField", // "statusField" \| "storedCache" \| "none" \| "triggerCache"

Design concepts

Sven the Barbarian — Sun, 23 Aug 2026 05:43:49 GMT

← Older revision		Revision as of 05:43, 23 August 2026
Line 35:		Line 35:
	* [[Development environment]]		* [[Development environment]]
	* [[Test environment overview]]		* [[Test environment overview]]
	* [[Local test environment]]
	* [[Using Postman]]		* [[Using Postman]]
	* [[Git development]]		* [[Git development]]
Line 50:		Line 49:
	* [[Per Service Schemas]]		* [[Per Service Schemas]]
	* [[Standard Data Structures]]		* [[Standard Data Structures]]
	* [[Standard Config Table Per Service]]
	* [[User Data Handling]]		* [[User Data Handling]]
	*: (maybe removing)
	* [[Standard LogicalResults Per Service]]		* [[Standard LogicalResults Per Service]]
	* [[Standard FindData Per Service]]		* [[Standard FindData Per Service]]
Line 59:		Line 56:
	* [[Standard WebSocketTask Per Service]]		* [[Standard WebSocketTask Per Service]]
	* [[Error Handling Multi Thread Processing]]		* [[Error Handling Multi Thread Processing]]
	* [[Multi Thread Invocation]]
	* [[Copying large Dynamo data from to another service table]]		* [[Copying large Dynamo data from to another service table]]

2022-11-09 - Multi Thread Invocation

Sven the Barbarian — Sun, 23 Aug 2026 05:43:03 GMT

← Older revision		Revision as of 05:43, 23 August 2026
(One intermediate revision by the same user not shown)
(No difference)

Multi Thread Invocation

Sven the Barbarian — Sun, 23 Aug 2026 05:41:52 GMT

Sven the Barbarian moved page Multi Thread Invocation to 2022-11-09 - Multi Thread Invocation

← Older revision		Revision as of 05:41, 23 August 2026
(One intermediate revision by the same user not shown)
Line 27:		Line 27:
	* Initial calling function saves AwaitingMultipleSteps for each thread		* Initial calling function saves AwaitingMultipleSteps for each thread
	* as each thread detects there are no remaining pages to process it clears it's AwaitingMultipleStep and checks if any awaiting steps remain, if not it continues the work flow		* as each thread detects there are no remaining pages to process it clears it's AwaitingMultipleStep and checks if any awaiting steps remain, if not it continues the work flow

			[[Category:Working documents\| 2022-11-09]]

Remote repository and workspace structure

Sven the Barbarian — Sun, 23 Aug 2026 05:34:33 GMT

← Older revision		Revision as of 05:34, 23 August 2026
Line 1:		Line 1:
	= Repository Design =		= Repository Design (Forgejo) =
	* One ~~workspace~~ per stack		* One organization per stack
	* If all repositories grouped together only need one project, same name as workspace
	* If have areas within stack
	* web service = one final project, eg: Izara Market

	= ~~Workspaces~~ =		= Core Stacks =

	== Izara Core - Libraries ==		== Izara Core - Libraries ==
Line 29:		Line 26:

	= Developers =		= Developers =
	* When working on a ~~workspace,~~ developer creates a ~~workspace~~ with the same name ~~suffixed with their name in brackets~~		* When working on a repository developer creates a fork with the same name suffixed with their name in brackets
	* That developer forks the repositories they are working on into this workspace, name of repository suffixed with their name in brackets		* If multiple developers working on the same repositories, only one person forks and names that repository, others fork/PR or push to developers fork
	* If multiple developers working on the same repositories, only one person forks and names that repository
	* name suffix of repositories will match the workspace forked into
	* copy the names of workspace/project/~~repository from originals, only adding name suffix in brackets~~

	~~= User Access =~~
	* Bitbuckets 5 developer limit is per workspace
	* by splitting into many workspaces we can more easily apply access to ~~people working on that code~~
	* always create User Groups for each workspace and apply to repositories (can apply as default access), so can easily adjust who has access

Test environment overview

Sven the Barbarian — Sun, 23 Aug 2026 05:30:26 GMT

← Older revision		Revision as of 05:30, 23 August 2026
Line 1:		Line 1:
	= Test environments =		= Test environments =

			* Old notes, now primarily use AI to check local developer code without mock AWS resources, [[Service - Integration Testing]] in AWS test environment, non-destructive tests in production environment could be implemented in the future

	There are three test environments to plan for:		There are three test environments to plan for:

Local test environment

Sven the Barbarian — Sun, 23 Aug 2026 05:26:46 GMT

← Older revision		Revision as of 05:26, 23 August 2026
Line 1:		Line 1:
	= Overview =		= Overview =

			* No longer used *

	Each repository is a micro-service that performs has responsibility for one part of the {{ProjectNameLong}}, although each is meant to be used as part of a network of interconnected micro-services when a single repository is cloned the first level of testing is at the self contained local level.		Each repository is a micro-service that performs has responsibility for one part of the {{ProjectNameLong}}, although each is meant to be used as part of a network of interconnected micro-services when a single repository is cloned the first level of testing is at the self contained local level.