Key/Index Mutation Scenario Matrix

matrix.md

Key/Index Mutation Scenario Matrix

Every permutation and its outcome at the key and index level. I have removed the following invalid scenarios:

• There are no "update" operations on the main table index (it's immutable)
• Only secondary indexes can have a "condition" function
• The condition function will never be called when the "PK Composites Provided" and "SK Composites Provided" are both none

Create (put, create, upsert)

Row	Impacted Index Type	PK Composites Provided	SK Composites Provided	Condition Present	Condition Returns	Throws	PK Action	SK Action	Index Outcome
1	table	none	none	false	-	true	n/a	n/a	n/a
2	table	none	some	false	-	true	n/a	n/a	n/a
3	table	none	all	false	-	true	n/a	n/a	n/a
4	table	some	none	false	-	true	n/a	n/a	n/a
5	table	some	some	false	-	true	n/a	n/a	n/a
6	table	some	all	false	-	true	n/a	n/a	n/a
7	table	all	none	false	-	true	n/a	n/a	n/a
8	table	all	some	false	-	true	n/a	n/a	n/a
9	table	all	all	false	-	false	write	write	present
10	secondary	none	some	true	true	false	skip	write	absent
11	secondary	none	some	true	false	false	skip	skip	absent
12	secondary	none	some	false	-	false	skip	write	absent
13	secondary	none	all	true	true	false	skip	write	absent
14	secondary	none	all	true	false	false	skip	skip	absent
15	secondary	none	all	false	-	false	skip	write	absent
16	secondary	some	none	true	true	false	skip	write	absent
17	secondary	some	none	true	false	false	skip	write	absent
18	secondary	some	none	false	-	false	skip	write	absent
19	secondary	some	some	true	true	false	skip	write	absent
20	secondary	some	some	true	false	false	skip	skip	absent
21	secondary	some	some	false	-	false	skip	write	absent
22	secondary	some	all	true	true	false	skip	write	absent
23	secondary	some	all	true	false	false	skip	skip	absent
24	secondary	some	all	false	-	false	skip	write	absent
25	secondary	all	none	true	true	false	write	write	present
26	secondary	all	none	true	false	false	skip	skip	absent
27	secondary	all	none	false	-	false	write	write	present
28	secondary	all	some	true	true	false	write	write	present
29	secondary	all	some	true	false	false	skip	skip	absent
30	secondary	all	some	false	-	false	write	write	present
31	secondary	all	all	true	true	false	write	write	present
32	secondary	all	all	true	false	false	skip	skip	absent
33	secondary	all	all	false	-	false	write	write	present

Create (Row 1)

Throws

All composite keys for the table index are required; without them, ElectroDB will be unable to form the item's key identifiers.

PK Action

Action throws so the item will not be created.

SK Action

Action throws so the item will not be created.

Index Outcome

Action throws so the item will not be created.

Create (Row 2)

Throws

All composite keys for the table index are required; without them, ElectroDB will be unable to form the item's key identifiers.

PK Action

Action throws so the item will not be created.

SK Action

Action throws so the item will not be created.

Index Outcome

Action throws so the item will not be created.

Create (Row 3)

Throws

All composite keys for the table index are required; without them, ElectroDB will be unable to form the item's key identifiers.

PK Action

Action throws so the item will not be created.

SK Action

Action throws so the item will not be created.

Index Outcome

Action throws so the item will not be created.

Create (Row 4)

Throws

All composite keys for the table index are required; without them, ElectroDB will be unable to form the item's key identifiers.

PK Action

Action throws so the item will not be created.

SK Action

Action throws so the item will not be created.

Index Outcome

Action throws so the item will not be created.

Create (Row 5)

Throws

All composite keys for the table index are required; without them, ElectroDB will be unable to form the item's key identifiers.

PK Action

Action throws so the item will not be created.

SK Action

Action throws so the item will not be created.

Index Outcome

Action throws so the item will not be created.

Create (Row 6)

Throws

All composite keys for the table index are required; without them, ElectroDB will be unable to form the item's key identifiers.

PK Action

Action throws so the item will not be created.

SK Action

Action throws so the item will not be created.

Index Outcome

Action throws so the item will not be created.

Create (Row 7)

Throws

All composite keys for the table index are required; without them, ElectroDB will be unable to form the item's key identifiers.

PK Action

Action throws so the item will not be created.

SK Action

Action throws so the item will not be created.

Index Outcome

Action throws so the item will not be created.

Create (Row 8)

Throws

All composite keys for the table index are required; without them, ElectroDB will be unable to form the item's key identifiers.

PK Action

Action throws so the item will not be created.

SK Action

Action throws so the item will not be created.

Index Outcome

Action throws so the item will not be created.

Create (Row 9)

Throws

All composite keys for the table index are provided, the item can be created.

PK Action

All composite keys for the table index are provided, the item's identifiers can be formed.

SK Action

All composite keys for the table index are provided, the item's identifiers can be formed.

Index Outcome

All composite keys for the table index are provided, the item's identifiers can be formed so the index appears on this index.

Create (Row 10)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

Without PK attributes, the PK cannot be formed which means it won't be accessible and therefore it is not written.

SK Action

The sort key will be written to the extent that it can be formatted.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 11)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

SK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

Index Outcome

The item will not be present on the index because the user returned a false value from their condition callback

Create (Row 12)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

No key will be written because none of composite attributes were provided, making it unable to format the key.

SK Action

ElectroDB will write the sort key to the extent that it can be formatted; this will ensure that the item's sort key is in sync with the attributes on the item.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 13)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

No key will be written because none of composite attributes were provided, making it unable to format the key.

SK Action

ElectroDB will write the sort key to the extent that it can be formatted; this will ensure that the item's sort key is in sync with the attributes on the item.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 14)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

No key will be written because none of composite attributes were provided, making it unable to format the key. Also, the key will not be written because the user returned a false value from their condition callback.

SK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index. Also the item will not be present on the index because the user returned a false value from their condition callback.

Create (Row 15)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

No key will be written because none of composite attributes were provided, making it unable to format the key.

SK Action

ElectroDB will write the sort key to the extent that it can be formatted; this will ensure that the item's sort key is in sync with the attributes on the item.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 16)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write a PK value because some composite attributes were not provided, therefore ElectroDB will be unable to format the entire key. On the query side, it would not be possible to access this item because the PK is not complete.

SK Action

ElectroDB will complete the SK to its fullest extent. If this is surprising to the reader, consider that if the sort key is formatted such that it has non-value prefixes (e.g., the default ElectroDB template prefixes the sort key with the entity name and version), Electro includes these values when performing a query without providing sort key attributes. Writing this prefix will ensure the item is accessible if the user queries for items without providing sort key attributes.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 17)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write a PK value because some composite attributes were not provided, therefore ElectroDB will be unable to format the entire key. On the query side, it would not be possible to access this item because the PK is not complete.

SK Action

ElectroDB will complete the SK to its fullest extent. If this is surprising to the reader, consider that if the sort key is formatted such that it has non-value prefixes (e.g., the default ElectroDB template prefixes the sort key with the entity name and version), Electro includes these values when performing a query without providing sort key attributes. Writing this prefix will ensure the item is accessible if the user queries for items without providing sort key attributes.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 18)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write a PK value because some composite attributes were not provided, therefore ElectroDB will be unable to format the entire key. On the query side, it would not be possible to access this item because the PK is not complete.

SK Action

ElectroDB will complete the SK to its fullest extent. If this is surprising to the reader, consider that if the sort key is formatted such that it has non-value prefixes (e.g., the default ElectroDB template prefixes the sort key with the entity name and version), Electro includes these values when performing a query without providing sort key attributes. Writing this prefix will ensure the item is accessible if the user queries for items without providing sort key attributes.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 19)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write a PK value because some composite attributes were not provided, therefore ElectroDB will be unable to format the entire key. On the query side, it would not be possible to access this item because the PK is not complete.

SK Action

ElectroDB will write the sort key to the extent that it can be formatted; this will ensure that the item's sort key is in sync with the attributes on the item.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 20)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

SK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

Index Outcome

The item will not be present on the index because the user returned a false value from their condition callback. Also, because the PK could not be formed, it was skipped and therefore the item will not be present on the index.

Create (Row 21)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write a PK value because some composite attributes were not provided, therefore ElectroDB will be unable to format the entire key. On the query side, it would not be possible to access this item because the PK is not complete.

SK Action

ElectroDB will write the sort key to the extent that it can be formatted; this will ensure that the item's sort key is in sync with the attributes on the item.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 22)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write a PK value because some composite attributes were not provided, therefore ElectroDB will be unable to format the entire key. On the query side, it would not be possible to access this item because the PK is not complete.

SK Action

ElectroDB will write the sort key to the extent that it can be formatted; this will ensure that the item's sort key is in sync with the attributes on the item.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 23)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write a PK value because some composite attributes were not provided, therefore ElectroDB will be unable to format the entire key. On the query side, it would not be possible to access this item because the PK is not complete.

SK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 24)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write a PK value because some composite attributes were not provided, therefore ElectroDB will be unable to format the entire key. On the query side, it would not be possible to access this item because the PK is not complete.

SK Action

ElectroDB will write the sort key to the extent that it can be formatted; this will ensure that the item's sort key is in sync with the attributes on the item.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 25)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB was provided all composite key attributes, allowing the full PK to be written.

SK Action

ElectroDB will complete the SK to its fullest extent. If this is surprising to the reader, consider that if the sort key is formatted such that it has non-value prefixes (e.g., the default ElectroDB template prefixes the sort key with the entity name and version), Electro includes these values when performing a query without providing sort key attributes. Writing this prefix will ensure the item is accessible if the user queries for items without providing sort key attributes.

Index Outcome

ElectroDB will write both the PK and SK keys, which will make the item present on item.

Create (Row 26)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

SK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

Index Outcome

The item will not be present on the index because the user returned a false value from their condition callback. Also, because the PK could not be formed, it was skipped and therefore the item will not be present on the index.

Create (Row 27)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB was provided all composite key attributes, allowing the full PK to be written.

SK Action

ElectroDB will complete the SK to its fullest extent. If this is surprising to the reader, consider that if the sort key is formatted such that it has non-value prefixes (e.g., the default ElectroDB template prefixes the sort key with the entity name and version), Electro includes these values when performing a query without providing sort key attributes. Writing this prefix will ensure the item is accessible if the user queries for items without providing sort key attributes.

Index Outcome

ElectroDB will write both the PK and SK keys, which will make the item present on item.

Create (Row 28)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB was provided all composite key attributes, allowing the full PK to be written.

SK Action

ElectroDB will write the sort key to the extent that it can be formatted; this will ensure that the item's sort key is in sync with the attributes on the item.

Index Outcome

ElectroDB will write both the PK and SK keys, which will make the item present on item.

Create (Row 29)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

SK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 30)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB was provided all composite key attributes, allowing the full PK to be written.

SK Action

ElectroDB will write the sort key to the extent that it can be formatted; this will ensure that the item's sort key is in sync with the attributes on the item.

Index Outcome

ElectroDB will write both the PK and SK keys, which will make the item present on item.

Create (Row 31)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB was provided all composite key attributes, allowing the full PK to be written.

SK Action

ElectroDB will write the sort key to the extent that it can be formatted; this will ensure that the item's sort key is in sync with the attributes on the item.

Index Outcome

ElectroDB will write both the PK and SK keys, which will make the item present on item.

Create (Row 32)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

SK Action

ElectroDB will not write the key because the user's condition callback returned a false value.

Index Outcome

ElectroDB could not fully form the PK, therefore it will not write a PK value, removing the item's presence on the index.

Create (Row 33)

Throws

The create operation would overwrite any existing record, so partial keys will not result in out-of-sync attributes/keys. The item can be safely created, so ElectroDB will not throw.

PK Action

ElectroDB was provided all composite key attributes, allowing the full PK to be written.

SK Action

ElectroDB will write the sort key to the extent that it can be formatted; this will ensure that the item's sort key is in sync with the attributes on the item.

Index Outcome

ElectroDB will write both the PK and SK keys, which will make the item present on item.

Update (update, patch)

Row	Impacted Index Type	PK Composites Provided	SK Composites Provided	Condition Present	Condition Returns	Throws	PK Action	SK Action	Index Outcome
1	secondary	none	some	true	true	true	n/a	n/a	n/a
2	secondary	none	some	true	false	false	delete	delete	absent
3	secondary	none	some	false		true	n/a	n/a	n/a
4	secondary	none	all	true	true	true	n/a	n/a	n/a
5	secondary	none	all	true	false	false	delete	delete	absent
6	secondary	none	all	false		false	skip	write	unknown
7	secondary	some	none	true	true	true	n/a	n/a	n/a
8	secondary	some	none	true	false	false	delete	delete	absent
9	secondary	some	none	false		true	n/a	n/a	n/a
10	secondary	some	some	true	true	true	n/a	n/a	n/a
11	secondary	some	some	true	false	false	delete	delete	absent
12	secondary	some	some	false		true	n/a	n/a	n/a
13	secondary	some	all	true	true	true	n/a	n/a	n/a
14	secondary	some	all	true	false	false	delete	delete	absent
15	secondary	some	all	false		true	n/a	n/a	n/a
16	secondary	all	none	true	true	true	n/a	n/a	n/a
17	secondary	all	none	true	false	false	delete	delete	absent
18	secondary	all	none	false		false	write	skip	present
19	secondary	all	some	true	true	true	n/a	n/a	n/a
20	secondary	all	some	true	false	false	delete	delete	absent
21	secondary	all	some	false		true	n/a	n/a	n/a
22	secondary	all	all	true	true	false	write	write	present
23	secondary	all	all	true	false	false	delete	delete	absent
24	secondary	all	all	false		false	write	write	present

Update (Row 1)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 2)

Throws

The condition callback returned false, so the update will delete the associated index keys.

PK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

SK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

Index Outcome

ElectroDB delete the keys to this index because the user's condition callback returned a false value.

Update (Row 3)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 4)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 5)

Throws

The condition callback returned false, so the update will delete the associated index keys.

PK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

SK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

Index Outcome

ElectroDB delete the keys to this index because the user's condition callback returned a false value.

Update (Row 6)

Throws

Key attribute were either all provided in their entirety or not at all; no need to throw.

PK Action

Key not impacted by update, no need to apply change.

SK Action

Index Outcome

The PK was not impacted by the update, so the index will not be impacted either. The item will remain present or absent on the index depending on the current state of the item in DynamoDB.

Update (Row 7)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 8)

Throws

The condition callback returned false, so the update will delete the associated index keys.

PK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

SK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

Index Outcome

ElectroDB delete the keys to this index because the user's condition callback returned a false value.

Update (Row 9)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 10)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 11)

Throws

The condition callback returned false, so the update will delete the associated index keys.

PK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

SK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

Index Outcome

ElectroDB delete the keys to this index because the user's condition callback returned a false value.

Update (Row 12)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 13)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 14)

Throws

The condition callback returned false, so the update will delete the associated index keys.

PK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

SK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

Index Outcome

ElectroDB delete the keys to this index because the user's condition callback returned a false value.

Update (Row 15)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 16)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 17)

Throws

The condition callback returned false, so the update will delete the associated index keys.

PK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

SK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

Index Outcome

ElectroDB delete the keys to this index because the user's condition callback returned a false value.

Update (Row 18)

Throws

Key attribute were either all provided in their entirety or not at all; no need to throw.

PK Action

The key will be written because all of its composite attributes were provided, making it possible to format the key.

SK Action

Key not impacted by update, no need to apply change.

Index Outcome

The PK was written on this update so we know the item will exist on the index after the update is applied.

Update (Row 19)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 20)

Throws

The condition callback returned false, so the update will delete the associated index keys.

PK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

SK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

Index Outcome

ElectroDB delete the keys to this index because the user's condition callback returned a false value.

Update (Row 21)

Throws

Attempting to write a key with only some of the composite attributes will throw an error because the update risks creating an inconsistency between the key's values and the contributing attribute's values. To avoid this error, provide all members of an index's composite key (either via set or using the composite method).

PK Action

Action throws so the item is not updated.

SK Action

Action throws so the item is not updated.

Index Outcome

Action throws so the item is not updated.

Update (Row 22)

Throws

Key attribute were either all provided in their entirety or not at all; no need to throw.

PK Action

The key will be written because all of its composite attributes were provided, making it possible to format the key.

SK Action

The key will be written because all of its composite attributes were provided, making it possible to format the key.

Index Outcome

The PK was written on this update so we know the item will exist on the index after the update is applied.

Update (Row 23)

Throws

The condition callback returned false, so the update will delete the associated index keys.

PK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

SK Action

ElectroDB will delete this key because the user's condition callback returned a false value.

Index Outcome

ElectroDB delete the keys to this index because the user's condition callback returned a false value.

Update (Row 24)

Throws

Key attribute were either all provided in their entirety or not at all; no need to throw.

PK Action

The key will be written because all of its composite attributes were provided, making it possible to format the key.

SK Action

The key will be written because all of its composite attributes were provided, making it possible to format the key.

Index Outcome

The PK was written on this update so we know the item will exist on the index after the update is applied.

@tywalch Gonna take be a bit to digest all of this. Working with 57 abstract scenarios is much harder for me then examples haha. However I do have some first questions.

• What is the difference between none and skip in the PK/SK action columns?
• What is the difference between none and absent in the Index outcome column?
• There are multiple secondary scenarios where some SK attributes are provided. For example row 11 and 12 or more concerning rows 28 & 30. Wouldn't any write operation to the SK when we only have some of the attributes create consistency issues? Without a PK I guess this could be minor as one would not really be able to query on this index anyway. However in 28 & 30 this item does end up in the index and the SK would be inconsistent.

@tywalch I see you've made some updates. I don't get notified so I am trying to check back when i can. This is a bit easier to understand.

• I am still not sure about the amount of situations where the SK is some and we still write. Isn't this always a bad idea?

• I am also having trouble understanding what the condition scenarios actually do. true vs false vs `not existing. Do you have some general rules here to help understand. For example in Create row 11 vs row 20. Row 11 has no PK some of the SK and a condition that returns false. This causes the SK to write. However in row 20 we have some PK some SK and a condition that returns false and this causes the SK to skip. I must be missing something here, but why does the presence of some PK change things this way?

• The scenario I am still struggling with is how can a user have a sparse index with a SK composite including a field like updatedAt that is always calculated. If an item is in the sparse index all updates need to be written to the sparse index as well so the SK stays in sync with the latest updatedAt. However if the item is not in the sparse index then we get stuck in a situation where we will always have some of the SK composite (updatedAt) and possibly write partial data in there or get errors. This gets even trickier if some attributes for the sparse index PK or SK are optional.