1
votes

We have a group of related documents all sharing the same partition key. The thinking is simply grouping these up should be a case of querying on the partition key and stitching them together. What am I missing?

So Select * from c where c.CustomerId = "500"

Would return say 3 documents, Address, Sales and Invoices who all have a property named CustomerId , with a value of 500.

I appreciate its not the primary key and I am purposely omiitng a row key.

Perhaps not splitting the documents is the answer but then the different documents have different TTLs and this would then becone problematic, wouldnt it(

CustomerId is the partition key.

The ms docs say this is possible (citing a city = seattle ) example. Where their partitionkey is city....

So, what am I missing, a complete misunderstaning of querying is cosmos ? (i can say I know a partition key is used to break up related data into partitions) I didnt know this made it an unqueryable aspect.

Also I can query with partition key and rowkey no problem.

EDIT 2:

This works:

SELECT * FROM c WHERE c.CustomerId > "499" AND c.CustomerId < "501"

2

2 Answers

1
votes

Ok,

So the range query working was a bit of a lead. Custom indexing on the collection was causing issues.
At this moment, I have removed the custom indexing entirely and will build back up and then post a more specific answer.

What I did read was that the PartitionKey is implicitly indexed anyway. There was an index on this ALSO so maybe this was causing funnies.

Indexing Policies CosmosDB

0
votes

Maybe I'm not getting at all, but you have to be explicit about the value that you are looking for, I think is not the same:

c.CustomerId = "500"

VS

c.CustomerId = 500

because one is looking for text and the other one for a number, review how is stored your data, and it has to be the same if you want to perform the query using that value (and having in mind CustomerId is the Partition Key).