Mani Gandham

My feedback

  1. 3,842 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    128 comments  ·  Azure Cosmos DB  ·  Flag idea as inappropriate…  ·  Admin →

    Reopening this user voice item as our support for Skip/Take (Offset/Limit) was only limited to single partition queries.

    Update.

    The newly released .NET SDK v3 now includes support for x-partition queries using Offset/Limit. You can learn more about v3 SDK and try it and provide feedback on our github repo here.
    github.com/azure/azure-cosmos-dotnet-v3

    We will also be back-porting this functionality to our .NET v2 SDK. This work will begin shortly and we anticipate it to be released in September.

    Once that is released we will mark this feature as complete.

    Thank you for your patience and votes.

    Mani Gandham supported this idea  · 
    Mani Gandham commented  · 

    Looks like this has been released now for the SQL API: https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-query-reference

  2. 1,383 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    83 comments  ·  Storage » Tables  ·  Flag idea as inappropriate…  ·  Admin →
    Mani Gandham commented  · 

    Azure Table Storage is a key/value store (sometimes referred to as wide-column stores), similar to HBase, Cassandra, DynamoDB, BigTable, and others. The whole architecture is based around a sorted hashmap with partition and row keys, and that's where the scale and performance comes from. Secondary indexes do not really fit in this model.

    If you need secondary indexes then you'll likely have to do it yourself. Some providers automate this (like AWs DynamoDB) and others build a new offering on top (like Google Cloud Datastore). It seems Azure went with the extreme option via CosmosDB which is a full database service that can be accessed over the table API, although at that point it would probably better to just use the native document store interface and get all the richness. Either way, that's probably the only path forward if you don't want to manage indexes yourself.

Feedback and Knowledge Base