"One of the request inputs is not valid" - November SDK

Question

Hi there,

Since upgrading to the November SDK, my existing Development Storage queries are now crashing with the error One of the request inputs is not valid. The queries have not changed since the previous SDK.

I've already figured out what the problem is. I recreated my development db using CloudTableClient.CreateTablesFromModel, and looking in SQL Management Studio I can see all of the tables in the TableContainer table, however the SchemaXml column does not contain any properties, as there are currently no records.

I noticed the following in the updated documentation:

     In development storage, querying on a property that does not exist in the table returns an error. Such a query does not return an error in the cloud.

I proved my theory by adding a row to the table, which in turn populated the properties in the associated TableContainer record. My queries no longer crashed.

So from what I can understand, if you now intend to run a query, a record must have been previously inserted that contains the most recent properties???

Please tell me I'm wrong.

Thanks,
Anthony.

Answer 1

You are correct that you need to have at least a single entry with the required schema for the queries to work. As part of the improvements to the Development Storage, we have removed the need to create storag tables. This removes the need to have specialized type or process for table creation that needs to be maintained on every schema change. Unfortunately one side effect of that change is that storage does not have any schema until you have inserted elements from which it can deduce the schema. (This is a limitation of having SQL-based storage simulation and is not a problem in the cloud)

A solution is to insert one representative element at the time of table creation and then delete it. This will create the schema for the table and allow any future queries to behave correctly. (Note: if you keep multiple different schemas within a single table, you should insert one of each type or the superset of all fields)

Answer 2

Hi Aleks,

Unfortunately, the workaround applies only as long as you don't shut down the development storage service. This means that you cannot realiably use the following pattern, which is used in the AspProviders sample, for example.

if (tableStorage.CreateTableIfNotExist(entityName))
{
   // create a row
   // save changes
   // delete it
   // save changes
}

When you run this code for the first time, it creates the table and applies the workaround. However, if you then stop the development storage service *before* inserting any new rows and then restart it, this time it skips the workaround because the table already exists. If you then query the table, it fails.

It seems that to work reliably, you need to insert and delete the dummy row every time, not just when the table is actually created. Of course, this is only necessary to work locally, but the code still needs to be there.

Answer 3

Thanks for confirming this. So essentially you still need to keep your entities & development DB in sync by inserting a record each time your schema changes.

To make life easier for myself, I've updated my existing Development Storage Sync tool to do this for every entity using reflection. Because it's an external tool, you don't need to riddle your code with insert & delete statements and you can run it whenever you want.

It's on my blog: http://antscode.blogspot.com/2009/11/development-storage-sync-azure-november.html

Anthony.

Answer 4

Just to jump in on this thread, I've seen the same behaviour as Fernando (http://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/9a546856-6153-4a3a-8fa0-3b666648f8ae). It seems unacceptable that this is "by design" behaviour, I don't want to be inserting dummy data to every empty table I have just to stop exceptions on the dev fabric. I'd rather go back to the create table tool...any chance of a MSFT comment on this?