Question

If I have one object, ‘Student’, which will be associated with 2 ‘Course’ objects, I think I need to add the student to azure tables first with a partitionkey of ‘Class1_Student1’, and then again with ‘Class2_Student1’.

Considering this is the identical Student object with the exception of the PartitionKey, is this a duplicate object in azure? Or is this somehow recognized (by RowKey maybe?) as the same object?

So if I pull that student out of azure tables for any Course and update it, I would hope that I get that updated version for any other Course request.

How does Azure deal with this, and is there something I need to do to get the functionality I want?

Answer 1

In Windows Azure tables, the identity of an entity is its partition key and row key, so to Windows Azure, you have two completely unrelated students.

If you update one, it will have no impact on the other.

I can think of two strategies to get what I think you want:

1. Normalize. In the relational database world, this is standard practice. In each “course,” you would just have a reference to Student1. In a “students” table, each student would only appear once.
2. Maintain the denormalized scheme yourself. Because there are no cross-partition transactions in Windows Azure tables, this is tricky to do. I recommend using a queue… each change (“update Student1’s address to be foo”) needs to go on a queue, and the queue message is only deleted after all updates have been done (across all relevant courses). This way if your process dies in the middle of updating a student, the work can be picked up and finished later.