Запитването в табличното хранилище на Azure не работи след определен брой обекти?

Помислете за моя сценарий. Имам около 200 дяла и всеки дял има около 1000 ключа на ред (обекти) или дори повече. Така че, когато правя заявка за извличане на записи на дял, който е последен по азбучен ред (започващ с "z"), тя не връща никакви резултати.

По-долу е примерна заявка -

audioRecordServiceContext.QueryableEntities
                         .Where(p => p.PartitionKey == channel && 
                                     p.IsDedication == true && 
                                     p.IsBroadcast == true && 
                                     p.BroadcastTime >= time && 
                                     p.BroadcastTime < time.AddHours(1))
                         .ToList();

Когато предам канал, започващ с начални азбуки, той връща обекти правилно, но когато дам канал, започващ вероятно с "Z", той не връща никакви обекти.

Някаква идея как мога да се справя с този проблем?

РЕДАКТИРАНЕ:

Низ на заявка

http://sampleservice/devstoreaccount1/AudioRecord()?$filter=Username eq 'username'

Отговор на Fiddler за заявката

**HTTP/1.1 200 OK
Cache-Control: no-cache
Transfer-Encoding: chunked
Content-Type: application/atom+xml;charset=utf-8
Server: Windows-Azure-Table/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 06dff157-f693-49a6-ade7-b7165a4d3dfb
x-ms-version: 2009-09-19
x-ms-continuation-NextPartitionKey: 1!16!QWZnaGFuaXN0YW4-
x-ms-continuation-NextRowKey: 1!48!YTZiOGQxZmYtYjNkYy00NDEyLTk2YmItZTViNmUyMWNhYzJi
Date: Wed, 04 Sep 2013 12:19:03 GMT**

person Bitsian    schedule 27.08.2013    source източник
comment
пука ли ти за case-sensitivity?   -  person King King    schedule 27.08.2013
comment
каналът, който сравнявам, е точно съобразен с това, което има в таблицата, така че това не би трябвало да е проблем? Казаха ми, че съхранението на таблици в Azure може да изпраща заявки само до 1000 обекта/заявка, така че мисля, че тези 1000 обекта преминават в самите първоначални дялове? Възможно ли е това да е проблем?   -  person Bitsian    schedule 27.08.2013
comment
Ограничението от 1000 обекта не е фактор, тъй като вие предоставяте критерии за заявка, включително дяла. Опитвали ли сте да проверите данните с помощта на инструмент като zud.io?   -  person Mark Rendle    schedule 27.08.2013
comment
Когато изпълните заявката, стартирайте и Fiddler, за да можете да видите точно какво се изпраща по кабела. Можете да видите дали отговорът съдържа x-ms-NextPartitionKey и x-ms-NextRowKey заглавки. Би било полезно, ако можете да публикувате действителната заявка, изпратена до услугата за съхранение (повече се интересувам да видя частта от низа на заявката).   -  person Gaurav Mantri    schedule 27.08.2013
comment
Вероятно се дължи на факта, че получавате токени за продължение, които ви казват да следвате веригата от данни. Токените за продължение могат да се появят дори ако не са върнати обекти; това е, което Gaurav намеква. Методите ExecuteAll и ExecuteAllWithRetries се справят автоматично с маркерите за продължение. Вижте блога на smark за случилото се с него... ;) blog.smarx.com/posts/   -  person Herve Roggero    schedule 27.08.2013
comment
@HerveRoggero Извинения за късния отговор. Търсих как да се справя с токените за продължаване, но изглежда не мога да намеря метод ExecuteAll никъде в клиентската библиотека за съхранение. сменен ли е? Наистина ще съм благодарен, ако някой може да сподели някакъв код за обработка на токени за продължаване.   -  person Bitsian    schedule 02.09.2013
comment
@GauravMantri Хей! Използвали ли сте токените за продължение напоследък? Не успях да намеря метод ExecuteAll в никоя клиентска библиотека за съхранение. Заседнал съм по този въпрос от дни, наистина ще съм ви благодарен, ако можете да хвърлите малко светлина върху това как мога да се справя с токените за продължаване. За предпочитане някакъв последен примерен код. Благодаря   -  person Bitsian    schedule 04.09.2013
comment
Коя версия на клиентската библиотека за съхранение използвате? Също така, моля, споделете проследяването на Fiddler, както попитах по-горе.   -  person Gaurav Mantri    schedule 04.09.2013
comment
Използвам версия 1.7 и добавих проследяването на fiddler.   -  person Bitsian    schedule 04.09.2013
comment
@GauravMantri са добавили низа на заявката.   -  person Bitsian    schedule 04.09.2013


Отговори (1)


Ето примерен код, който извлича толкова обекти, колкото е необходимо въз основа на подадената заявка; в моята среда това връща над 10 000 обекта и автоматично обработва токените за продължение. Не съм 100% сигурен за версията на SDK, която използва, но трябва да работи с 1.7. Магията тук се извършва от AsTableServiceQuery, който е метод за разширение, осигурен от SDK, който извършва както странирането, така и автоматичните повторни опити.

Променливата _tableName съдържа името на моята таблица.

CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConnectionString);
            CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
            TableServiceContext serviceContext = tableClient.GetDataServiceContext();

            var partitionQuery =
                (from e in serviceContext.CreateQuery<MyData1>(_tableName)
                 where e.PartitionKey.CompareTo("15") >= 0 && e.PartitionKey.CompareTo("39") <= 0
                 select new MyData1()
                 {
                     PartitionKey = e.PartitionKey,
                     RowKey = e.RowKey,
                     Timestamp = e.Timestamp,
                     Message = e.Message,
                     Level = e.Level,
                     Severity = e.Severity
                 }
                 ).AsTableServiceQuery();

            return partitionQuery.ToList<MyData1>();

Горният код зависи от клас, наречен MyData1, дефиниран като такъв:

public class MyData1 : TableServiceEntity
{
    public string Message { get; set; }
    public string Level { get; set; }
    public string Severity { get; set; }
}

Надявам се това да помогне...

person Herve Roggero    schedule 04.09.2013
comment
Благодаря много, това помогна! - person Bitsian; 05.09.2013