You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the Table Storage entities RepositoryEntity and PrEntity there are no PartitionKey or RowKey (strategies) defined yet. UserEntity, has Users as the PartitionKey and takes UserId.ToString() as the RowKey.
Will we be using static PartitionKeys (like Users for all users) for all table storage entities? This will help in having multiple types of entities in one table, but if we get to large amounts of users it might not help in performance if there are scenario's where we need to query entities other than all entities or a specific one.
The text was updated successfully, but these errors were encountered:
rickvdbosch
changed the title
Structure for Table Storage entities
PK/RK for Table Storage entities
Sep 29, 2020
Another question about the UserEntity Table Storage entity: it currently has a Guid as the Id, but the GitHub information does not contain a Guid we could use for this.
There is an Id field available which we could use. This is a numerical value (in my case it's 8 characters long), or we could use the login/username.
My recommendation would be to use login since it's unique and also says something about the actual user. Is this OK?
@rickvdbosch we have updated the userentity as i misunderstood the data comming from the GithubAPI. We are using the static "users" Partition as from what i understand it will lock down to indexing only needed on the rowkey. the userid field has been updated to github login as yes it's the unique key from github
For the Table Storage entities
RepositoryEntity
andPrEntity
there are no PartitionKey or RowKey (strategies) defined yet. UserEntity, hasUsers
as the PartitionKey and takesUserId.ToString()
as the RowKey.Will we be using static PartitionKeys (like
Users
for all users) for all table storage entities? This will help in having multiple types of entities in one table, but if we get to large amounts of users it might not help in performance if there are scenario's where we need to query entities other than all entities or a specific one.The text was updated successfully, but these errors were encountered: