Interrogazione della memoria della tabella azzurra per valori nulli

Question

Qualcuno conosce il modo corretto per interrogare la memoria della tabella azzerata per un valore nullo. Da quello che ho letto, è possibile (anche se c'è un bug che lo impedisce nello storage di sviluppo). Tuttavia, continuo a ricevere il seguente errore quando lo faccio nell'archivio cloud attivo:

Uno degli input di richiesta non è valido.

Questa è una versione obsoleta della query LINQ che ho creato.

var query = from fooBar in fooBarSVC.CreateQuery<FooBar>("FooBars") 
     where fooBar.PartitionKey == kPartitionID 
      && fooBar.Code == kfooBarCode 
      && fooBar.Effective_Date <= kFooBarDate.ToUniversalTime() 
      && (fooBar.Termination_Date > kFooBarDate.ToUniversalTime() || fooBar.Termination_Date == null) 
     select fooBar; 

Se si esegue la query senza verificare null, funziona correttamente. So che una possibile soluzione sarebbe quella di eseguire una seconda query sulla raccolta che questa query riporta. Non mi dispiace farlo se ne ho bisogno, ma vorrei sapere se riesco a far funzionare questo approccio per primo.

Chiunque vede qualcosa di ovvio, sto sbagliando?

Answer 1

Il problema è che poiché la memoria della tabella azzurra non ha uno schema, la colonna nulla in realtà non esiste. Questo è il motivo per cui la tua richiesta non è valida. non esiste una colonna nulla nella memoria della tabella. Potresti fare qualcosa come memorizzare una stringa vuota se davvero devi. In realtà, in questo caso, il problema fondamentale è che la memoria della tabella di Azure non è realmente costruita per essere interrogata da colonne diverse dalla chiave di partizione e dalla chiave di riga. Ogni volta che si effettua una query su una di queste colonne non standard si sta eseguendo una scansione della tabella. Se si iniziano a ottenere molti dati, si avrà un tasso molto elevato di timeout delle query. Suggerirei di impostare un indice manuale per questi tipi di query. Ad esempio, è possibile memorizzare gli stessi dati nella stessa tabella ma con valori diversi per la chiave Row. In definitiva, se la tua app non sta diventando pazzesca, utilizzerei semplicemente SQL Azure in quanto sarà molto più flessibile per i tipi di query che stai facendo.

Aggiornamento: Azure offre un'ottima guida per la progettazione di un contenitore da tavolo che consiglio di leggere. http://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/