01
Compare the complete entity identity
An Azure Table entity is identified within its table by PartitionKey and RowKey. Confirm the endpoint, table, and both values. An accidental constant key or a repeated event can target the same entity even when other properties differ.
The lab first created an orders/1 entity with Status=new. Creating another entity with the same key but a different status returned 409. Reading it afterward showed that the original value had not been replaced.
entity = {"PartitionKey": "orders", "RowKey": "1", "Status": "new"}
table.create_entity(entity)
# A second create with the same key is not an update operation.02
Keep create-only behavior when it is intentional
If the operation must not overwrite an existing entity, handle the conflict explicitly. Determine whether a repeated request represents an already completed idempotent operation or a genuine business conflict. Compare the relevant state rather than returning success for every duplicate.
The Python SDK raises ResourceExistsError for the tested duplicate create. Catch that specific outcome without swallowing unrelated authorization, network, or validation errors. The application still needs to decide what the existing record means.
from azure.core.exceptions import ResourceExistsError
try:
table.create_entity(entity)
except ResourceExistsError:
existing = table.get_entity(entity["PartitionKey"], entity["RowKey"])
# Apply the application's duplicate/conflict decision to existing.
# Do not silently assume every existing record is equivalent.03
Use upsert only for an intentionally updateable entity
An upsert changes the contract: it can create or update. Merge mode updates supplied properties while preserving others; replacement semantics can remove omitted properties. Choose the behavior deliberately rather than using upsert as a universal way to hide 409 responses.
Our second lab operation was an explicitly intended status update, so a merge upsert was appropriate for that demonstration. It updated Status to explicit-update and the readback confirmed the result.
from azure.data.tables import UpdateMode
# Use only when this create-or-update behavior is intended.
table.upsert_entity(
{"PartitionKey": "orders", "RowKey": "1", "Status": "explicit-update"},
mode=UpdateMode.MERGE,
)04
Treat competing updates as another requirement
A successful merge upsert does not by itself prevent one worker from overwriting another worker’s value for the same property. If the update depends on a version previously read, use an appropriate conditional update strategy and handle conflicts.
The local test checks create-versus-upsert semantics only. It did not prove that a particular application’s duplicate detection, ETag strategy, or multi-worker workflow is correct. Keep those decisions visible instead of calling every 409 a retry problem.
05
Verify the stored result and operation outcome
After the intended operation, read the exact entity through an authorized path and compare the relevant non-sensitive fields. A create conflict should not have changed the original record; an intentional update should have produced the chosen new state.
Keep a small regression test for repeated delivery or repeated form submission. Record the complete key context and outcome without dumping private entity properties. That protects the business contract when storage code is refactored.
Sınırları bil
Reproduced with Azurite Table storage and azure-data-tables 12.7.0. A duplicate create returned 409 and preserved the original status. A separately intended merge upsert updated that field. This does not validate Cosmos DB Table behavior or a production concurrency policy.
Kaynaklar ve ileri okuma
CoreTrailKit tarafından hazırlanan teknik yayın.
Bütün yazıları keşfet