Modifying entities with the REST API is CRUD (part 2) - Deleting entities

2. Deleting entities

You could delete shirts from the product list using the following call:

var shirtContext = new ProductContext();
shirtContext.DeleteObject(shirtToDelete);
shirtContext.SaveChanges();

Deleting an entity is similar to adding an entity when using the StorageClient library. If you wished to delete a shirt from the Products table, you’d need to add the shirt to be deleted to the context object’s (shirtContext) tracking list using the DeleteObject method. All changes are again tracked locally by the context object and are only saved back to the Table service when the SaveChanges method is called (following the Unit of Work pattern).

Let’s now take a look at using the REST API for deleting entities from a table. To delete an entity you need to make a DELETE request to the appropriate URI, passing in the correct table name, partition key, and row key:

http://silverlightukstorage.table.core.windows.net/Products(PartitionKey="Shirts", RowKey="RedShirt")

					  

Listing 1. Deleting entities using the REST API

Optimizing Delete Performance in Web Grids

As explained previously, to delete an entity using the StorageClient library, you first need to add a local copy of the entity to your context object’s tracking list. In Windows client applications, this isn’t such a big issue, as you’ll already have a local copy of the entities. In an ASP.NET application, if you listed the entities in a grid (as in the product-management web page), you’d no longer have a local copy of the entity because each web page call is stateless.

Although you could store a copy of all entities in the ASP.NET page state, this would massively increase the page size and reduce overall performance. Similarly, storing the entities in the session would put unnecessary overhead on the web server, again affecting the performance. Even if the grid were populated from a cache, unnecessary calls to the cache would still have a slight impact on performance. So let’s look at some other options.

We fetched the entity from the Table service (for the sake of simplicity) and then added that entity to the shirtContext’s tracking list. The following code shows how we used a LINQ query to fetch the data from the Table service:

var entity = new ProductContext();

shirtToDelete = (from item in shirtContext.Products
        where item.PartitionKey == "Shirts"
        && item.RowKey == rowkey
                 select item).First();

shirtContext.DeleteObject(entity);

shirtContext.SaveChanges();

Refetching the entity to be deleted isn’t something you should consider in a production environment, as any unnecessary calls to the Table service will impact the performance of your application and add to the overall running cost of your service (calls to the Table service are billable).

As you saw in our discussion of the REST API, you really don’t need all the data of the object. In fact, you only need the partition key and row key, so rather than fetching the whole object, you could construct a lightweight version of the object to be deleted.

To do this, you can define a lightweight sister class of the Product class that only contains the PartitionKey and RowKey values. As long as the object held in the tracking list holds the correct PartitionKey and RowKey (which uniquely identify an entity), you’ll have enough information to perform the delete—there’s no need to fetch every property of the entity.

The following code shows how you can delete an entity from the Table service using a lightweight instance:

var shirtContext = new ProductContext();
shirtContext.DeleteObject
(
   new ProductKey
   {
      PartitionKey = "Shirts",
      RowKey = e.CommandArgument.ToString()
   }
);
   shirtContext.AttachTo("Product", entity, "*");
shirtContext.SaveChanges(saveOptions);

As you can see in the preceding code, there’s no need to fetch the entity from the Table service because you already know the PartitionKey (Shirts), and the RowKey can be extracted from the command argument of the Delete button. This optimization saves you that extra fetch.

Now that we’ve explored both inserting and deleting, it’s time to complete the set and look at updates.