wherekeys() expects both partitionKey and rowKey to be not null about azure-sdk-for-node

[jbueza]

Hey @nikhilhasija -- Wouldn't it be best if you just used the following example to return all records given a specific partition key?

https://www.windowsazure.com/en-us/develop/nodejs/how-to-guides/table-services/#query-set-entities

[jbueza]

We can close this issue -- if @nikhilhasija has another use case that the above example doesn't solve, we can re-open.

[andrerod]

Although you are correct Jaime, I think that we could indeed probably be flexible here. whereKeys was indeed designed having in mind the query single entity flow, but we could extend it to be flexible and adjust "automagically" the query in case, both, only one or none of the keys (Partition / Row) is provided.

Would you agree Jaime ?

[jbueza]

+1 on that @andrerod -- Hint hint to the community to land this feature + tests ;)

[nikhilhasija]

Thanks @andrerod I support it :)

I think most of the time, the way I am designing my interfaces, PartitionKey is extracted from the data and often there is no where clause (although a where clause simply filters it down further). When I looked at the code, it seemed that making a call using only whereKeys may be more efficient that building a where clause (few ticks but in node i try to avoid, any compute necessary).

Also there is a matter of convention causing confusion.. In node.js variable convention the partition key is referred to as 'partitionKey' while in Azure tables it is 'PartitionKey'... moving the query to a where clause took me a while to decipher as why my data was not showing up as I was using 'partitionKey eq ?' erroneously...

[andrerod]

Glad you guys aprove :-) If no one else takes this, expect some updates after the holidays.

[andrerod]

Fixed.

[nikhilhasija]

Awesome.

On Mar 15, 2012, at 5:09 PM, Andr Rodrigues wrote:

Fixed.

---

Reply to this email directly or view it on GitHub:
#16 (comment)