quidproquo-actionprocessor-awslambda 0.1.22 → 0.1.23
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/lib/commonjs/logic/dynamo/qpqDynamoOrm/getDynamoTableIndexByConfigAndQuery.d.ts +8 -0
- package/lib/commonjs/logic/dynamo/qpqDynamoOrm/getDynamoTableIndexByConfigAndQuery.js +10 -5
- package/lib/commonjs/logic/dynamo/qpqDynamoOrm/getDynamoTableIndexByConfigAndQuery.js.map +1 -1
- package/lib/esm/logic/dynamo/qpqDynamoOrm/getDynamoTableIndexByConfigAndQuery.d.ts +8 -0
- package/lib/esm/logic/dynamo/qpqDynamoOrm/getDynamoTableIndexByConfigAndQuery.js +10 -5
- package/lib/esm/logic/dynamo/qpqDynamoOrm/getDynamoTableIndexByConfigAndQuery.js.map +1 -1
- package/package.json +7 -7
|
@@ -3,5 +3,13 @@ import { KeyValueStoreQPQConfigSetting, KvsQueryOperation, Nullable } from 'quid
|
|
|
3
3
|
* Pick the GSI that can serve the query, or null to query the primary table.
|
|
4
4
|
* Returns the GSI's partition key name, which is also its index name (the CDK
|
|
5
5
|
* construct names each GSI after its partition key).
|
|
6
|
+
*
|
|
7
|
+
* A Query MUST constrain the partition key of whatever it runs against. So: if
|
|
8
|
+
* the query names the primary partition key, the primary table can serve it
|
|
9
|
+
* (strongly consistent, and its sort key is available) - prefer it over any GSI.
|
|
10
|
+
* Otherwise route to the GSI whose partition key the query names. Deciding on
|
|
11
|
+
* the primary SORT key instead is wrong: a GSI commonly has the primary sort key
|
|
12
|
+
* as its partition key (pk userId / sk tenantId with a GSI on tenantId), and a
|
|
13
|
+
* query on that key alone can only be served by the GSI.
|
|
6
14
|
*/
|
|
7
15
|
export declare const getDynamoTableIndexByConfigAndQuery: (setting: KeyValueStoreQPQConfigSetting, query: KvsQueryOperation) => Nullable<string>;
|
|
@@ -6,15 +6,20 @@ const flattenKvsQueryConditions_1 = require("./flattenKvsQueryConditions");
|
|
|
6
6
|
* Pick the GSI that can serve the query, or null to query the primary table.
|
|
7
7
|
* Returns the GSI's partition key name, which is also its index name (the CDK
|
|
8
8
|
* construct names each GSI after its partition key).
|
|
9
|
+
*
|
|
10
|
+
* A Query MUST constrain the partition key of whatever it runs against. So: if
|
|
11
|
+
* the query names the primary partition key, the primary table can serve it
|
|
12
|
+
* (strongly consistent, and its sort key is available) - prefer it over any GSI.
|
|
13
|
+
* Otherwise route to the GSI whose partition key the query names. Deciding on
|
|
14
|
+
* the primary SORT key instead is wrong: a GSI commonly has the primary sort key
|
|
15
|
+
* as its partition key (pk userId / sk tenantId with a GSI on tenantId), and a
|
|
16
|
+
* query on that key alone can only be served by the GSI.
|
|
9
17
|
*/
|
|
10
18
|
const getDynamoTableIndexByConfigAndQuery = (setting, query) => {
|
|
11
19
|
var _a;
|
|
12
20
|
const queriedKeys = (0, flattenKvsQueryConditions_1.flattenKvsQueryConditions)(query).map((condition) => condition.key);
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
// condition.
|
|
16
|
-
const primarySortKey = (_a = setting.sortKeys[0]) === null || _a === void 0 ? void 0 : _a.key;
|
|
17
|
-
if (primarySortKey && queriedKeys.includes(primarySortKey)) {
|
|
21
|
+
const primaryPartitionKey = (_a = setting.partitionKey) === null || _a === void 0 ? void 0 : _a.key;
|
|
22
|
+
if (primaryPartitionKey && queriedKeys.includes(primaryPartitionKey)) {
|
|
18
23
|
return null;
|
|
19
24
|
}
|
|
20
25
|
const matchingIndex = setting.indexes.find((index) => queriedKeys.includes(index.partitionKey.key));
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"getDynamoTableIndexByConfigAndQuery.js","sourceRoot":"","sources":["../../../../../src/logic/dynamo/qpqDynamoOrm/getDynamoTableIndexByConfigAndQuery.ts"],"names":[],"mappings":";;;AAEA,2EAAwE;AAExE
|
|
1
|
+
{"version":3,"file":"getDynamoTableIndexByConfigAndQuery.js","sourceRoot":"","sources":["../../../../../src/logic/dynamo/qpqDynamoOrm/getDynamoTableIndexByConfigAndQuery.ts"],"names":[],"mappings":";;;AAEA,2EAAwE;AAExE;;;;;;;;;;;;GAYG;AACI,MAAM,mCAAmC,GAAG,CAAC,OAAsC,EAAE,KAAwB,EAAoB,EAAE;;IACxI,MAAM,WAAW,GAAG,IAAA,qDAAyB,EAAC,KAAK,CAAC,CAAC,GAAG,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC;IAEvF,MAAM,mBAAmB,GAAG,MAAA,OAAO,CAAC,YAAY,0CAAE,GAAG,CAAC;IACtD,IAAI,mBAAmB,IAAI,WAAW,CAAC,QAAQ,CAAC,mBAAmB,CAAC,EAAE,CAAC;QACrE,OAAO,IAAI,CAAC;IACd,CAAC;IAED,MAAM,aAAa,GAAG,OAAO,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,WAAW,CAAC,QAAQ,CAAC,KAAK,CAAC,YAAY,CAAC,GAAG,CAAC,CAAC,CAAC;IAEpG,OAAO,aAAa,CAAC,CAAC,CAAC,aAAa,CAAC,YAAY,CAAC,GAAG,CAAC,CAAC,CAAC,IAAI,CAAC;AAC/D,CAAC,CAAC;AAXW,QAAA,mCAAmC,uCAW9C","sourcesContent":["import { KeyValueStoreQPQConfigSetting, KvsQueryOperation, Nullable } from 'quidproquo-core';\n\nimport { flattenKvsQueryConditions } from './flattenKvsQueryConditions';\n\n/**\n * Pick the GSI that can serve the query, or null to query the primary table.\n * Returns the GSI's partition key name, which is also its index name (the CDK\n * construct names each GSI after its partition key).\n *\n * A Query MUST constrain the partition key of whatever it runs against. So: if\n * the query names the primary partition key, the primary table can serve it\n * (strongly consistent, and its sort key is available) - prefer it over any GSI.\n * Otherwise route to the GSI whose partition key the query names. Deciding on\n * the primary SORT key instead is wrong: a GSI commonly has the primary sort key\n * as its partition key (pk userId / sk tenantId with a GSI on tenantId), and a\n * query on that key alone can only be served by the GSI.\n */\nexport const getDynamoTableIndexByConfigAndQuery = (setting: KeyValueStoreQPQConfigSetting, query: KvsQueryOperation): Nullable<string> => {\n const queriedKeys = flattenKvsQueryConditions(query).map((condition) => condition.key);\n\n const primaryPartitionKey = setting.partitionKey?.key;\n if (primaryPartitionKey && queriedKeys.includes(primaryPartitionKey)) {\n return null;\n }\n\n const matchingIndex = setting.indexes.find((index) => queriedKeys.includes(index.partitionKey.key));\n\n return matchingIndex ? matchingIndex.partitionKey.key : null;\n};\n"]}
|
|
@@ -3,5 +3,13 @@ import { KeyValueStoreQPQConfigSetting, KvsQueryOperation, Nullable } from 'quid
|
|
|
3
3
|
* Pick the GSI that can serve the query, or null to query the primary table.
|
|
4
4
|
* Returns the GSI's partition key name, which is also its index name (the CDK
|
|
5
5
|
* construct names each GSI after its partition key).
|
|
6
|
+
*
|
|
7
|
+
* A Query MUST constrain the partition key of whatever it runs against. So: if
|
|
8
|
+
* the query names the primary partition key, the primary table can serve it
|
|
9
|
+
* (strongly consistent, and its sort key is available) - prefer it over any GSI.
|
|
10
|
+
* Otherwise route to the GSI whose partition key the query names. Deciding on
|
|
11
|
+
* the primary SORT key instead is wrong: a GSI commonly has the primary sort key
|
|
12
|
+
* as its partition key (pk userId / sk tenantId with a GSI on tenantId), and a
|
|
13
|
+
* query on that key alone can only be served by the GSI.
|
|
6
14
|
*/
|
|
7
15
|
export declare const getDynamoTableIndexByConfigAndQuery: (setting: KeyValueStoreQPQConfigSetting, query: KvsQueryOperation) => Nullable<string>;
|
|
@@ -3,14 +3,19 @@ import { flattenKvsQueryConditions } from './flattenKvsQueryConditions';
|
|
|
3
3
|
* Pick the GSI that can serve the query, or null to query the primary table.
|
|
4
4
|
* Returns the GSI's partition key name, which is also its index name (the CDK
|
|
5
5
|
* construct names each GSI after its partition key).
|
|
6
|
+
*
|
|
7
|
+
* A Query MUST constrain the partition key of whatever it runs against. So: if
|
|
8
|
+
* the query names the primary partition key, the primary table can serve it
|
|
9
|
+
* (strongly consistent, and its sort key is available) - prefer it over any GSI.
|
|
10
|
+
* Otherwise route to the GSI whose partition key the query names. Deciding on
|
|
11
|
+
* the primary SORT key instead is wrong: a GSI commonly has the primary sort key
|
|
12
|
+
* as its partition key (pk userId / sk tenantId with a GSI on tenantId), and a
|
|
13
|
+
* query on that key alone can only be served by the GSI.
|
|
6
14
|
*/
|
|
7
15
|
export const getDynamoTableIndexByConfigAndQuery = (setting, query) => {
|
|
8
16
|
const queriedKeys = flattenKvsQueryConditions(query).map((condition) => condition.key);
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
// condition.
|
|
12
|
-
const primarySortKey = setting.sortKeys[0]?.key;
|
|
13
|
-
if (primarySortKey && queriedKeys.includes(primarySortKey)) {
|
|
17
|
+
const primaryPartitionKey = setting.partitionKey?.key;
|
|
18
|
+
if (primaryPartitionKey && queriedKeys.includes(primaryPartitionKey)) {
|
|
14
19
|
return null;
|
|
15
20
|
}
|
|
16
21
|
const matchingIndex = setting.indexes.find((index) => queriedKeys.includes(index.partitionKey.key));
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"getDynamoTableIndexByConfigAndQuery.js","sourceRoot":"","sources":["../../../../../src/logic/dynamo/qpqDynamoOrm/getDynamoTableIndexByConfigAndQuery.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,yBAAyB,EAAE,MAAM,6BAA6B,CAAC;AAExE
|
|
1
|
+
{"version":3,"file":"getDynamoTableIndexByConfigAndQuery.js","sourceRoot":"","sources":["../../../../../src/logic/dynamo/qpqDynamoOrm/getDynamoTableIndexByConfigAndQuery.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,yBAAyB,EAAE,MAAM,6BAA6B,CAAC;AAExE;;;;;;;;;;;;GAYG;AACH,MAAM,CAAC,MAAM,mCAAmC,GAAG,CAAC,OAAsC,EAAE,KAAwB,EAAoB,EAAE;IACxI,MAAM,WAAW,GAAG,yBAAyB,CAAC,KAAK,CAAC,CAAC,GAAG,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC;IAEvF,MAAM,mBAAmB,GAAG,OAAO,CAAC,YAAY,EAAE,GAAG,CAAC;IACtD,IAAI,mBAAmB,IAAI,WAAW,CAAC,QAAQ,CAAC,mBAAmB,CAAC,EAAE,CAAC;QACrE,OAAO,IAAI,CAAC;IACd,CAAC;IAED,MAAM,aAAa,GAAG,OAAO,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,WAAW,CAAC,QAAQ,CAAC,KAAK,CAAC,YAAY,CAAC,GAAG,CAAC,CAAC,CAAC;IAEpG,OAAO,aAAa,CAAC,CAAC,CAAC,aAAa,CAAC,YAAY,CAAC,GAAG,CAAC,CAAC,CAAC,IAAI,CAAC;AAC/D,CAAC,CAAC","sourcesContent":["import { KeyValueStoreQPQConfigSetting, KvsQueryOperation, Nullable } from 'quidproquo-core';\n\nimport { flattenKvsQueryConditions } from './flattenKvsQueryConditions';\n\n/**\n * Pick the GSI that can serve the query, or null to query the primary table.\n * Returns the GSI's partition key name, which is also its index name (the CDK\n * construct names each GSI after its partition key).\n *\n * A Query MUST constrain the partition key of whatever it runs against. So: if\n * the query names the primary partition key, the primary table can serve it\n * (strongly consistent, and its sort key is available) - prefer it over any GSI.\n * Otherwise route to the GSI whose partition key the query names. Deciding on\n * the primary SORT key instead is wrong: a GSI commonly has the primary sort key\n * as its partition key (pk userId / sk tenantId with a GSI on tenantId), and a\n * query on that key alone can only be served by the GSI.\n */\nexport const getDynamoTableIndexByConfigAndQuery = (setting: KeyValueStoreQPQConfigSetting, query: KvsQueryOperation): Nullable<string> => {\n const queriedKeys = flattenKvsQueryConditions(query).map((condition) => condition.key);\n\n const primaryPartitionKey = setting.partitionKey?.key;\n if (primaryPartitionKey && queriedKeys.includes(primaryPartitionKey)) {\n return null;\n }\n\n const matchingIndex = setting.indexes.find((index) => queriedKeys.includes(index.partitionKey.key));\n\n return matchingIndex ? matchingIndex.partitionKey.key : null;\n};\n"]}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "quidproquo-actionprocessor-awslambda",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.23",
|
|
4
4
|
"description": "",
|
|
5
5
|
"main": "./lib/commonjs/index.js",
|
|
6
6
|
"module": "./lib/esm/index.js",
|
|
@@ -66,11 +66,11 @@
|
|
|
66
66
|
"lodash": "^4.17.21",
|
|
67
67
|
"node-cache": "^5.1.2",
|
|
68
68
|
"node-match-path": "^0.6.3",
|
|
69
|
-
"quidproquo-actionprocessor-js": "0.1.
|
|
70
|
-
"quidproquo-actionprocessor-node": "0.1.
|
|
71
|
-
"quidproquo-config-aws": "0.1.
|
|
72
|
-
"quidproquo-core": "0.1.
|
|
73
|
-
"quidproquo-webserver": "0.1.
|
|
69
|
+
"quidproquo-actionprocessor-js": "0.1.23",
|
|
70
|
+
"quidproquo-actionprocessor-node": "0.1.23",
|
|
71
|
+
"quidproquo-config-aws": "0.1.23",
|
|
72
|
+
"quidproquo-core": "0.1.23",
|
|
73
|
+
"quidproquo-webserver": "0.1.23"
|
|
74
74
|
},
|
|
75
75
|
"devDependencies": {
|
|
76
76
|
"@types/busboy": "^1.5.0",
|
|
@@ -78,7 +78,7 @@
|
|
|
78
78
|
"@types/lodash": "^4.14.194",
|
|
79
79
|
"@types/node": "^22.13.13",
|
|
80
80
|
"esbuild": "^0.25.8",
|
|
81
|
-
"quidproquo-tsconfig": "0.1.
|
|
81
|
+
"quidproquo-tsconfig": "0.1.23",
|
|
82
82
|
"typescript": "^5.8.2"
|
|
83
83
|
}
|
|
84
84
|
}
|