Get count of items in a StringSet attribute

[simoami]

I have a user.followers attribute of type stringSet(). Is it possible to get the count of entries instead of the entire list of follower entries, which would be inefficient if the list has thousands of items.

Can the follower count be returned along with other properties? say:

id: 123
fullName: "John Doe"
// followers: [...] <- excluded
// following: [...] <- excluded
// favorites: [...] <- excluded
stats: {
  followers: 10
  following: 5,
  favorites: 3
}

[set-killer]

Why not putting the followers in another table with hash/range key?

[simoami]

can you elaborate on your suggestion? will I be able to load the count from other tables along with the user's common attributes?

[set-killer]

oh, nvm.

You may use the projection attribute in the index (so when you search by that index you will allays get the desired values) like this example

Or you may use ProjectionExpression property when loading the model.

In both cases you should manually sync the stats with the corresponding data. However, skipping some fields from the return list will not save you any read capacities.

[simoami]

@set-killer I ended up creating a separate table for followers as you had suggested. I found that architecturally this can provide some flexibility. Also, I couldn't find a way to mix counts with other properties. So I chained calls to get the user profile and then made a call for each count property: followers, following...etc.

[set-killer]

I wonder how is this going to work in production environment with a lot of records in the database.

If this approach still consumes a lot of capacities you can mix the both approaches:

• having a property stats in your User profile schema (PRO: you can skip the COUNT query from followers/following/favorites; CON: every time a user follows/unfollows/favorites something the user profile have to be updated, which may require more write capacities). Read capacities are cheaper than write capacities. It depends which is more often used by the users. This would require some more code to sync up the stats fields when necessary.
• still having separate tables for followers/following/favorites - easier to implement pagination and timestamp for the creation of the record.

Btw, Instead of chaining the calls for the counts of followers/following/favorites you may perform the queries asynchronously with async.parallel. It would speed up the process as every table has its own capacities.