Request: Ability to store multiple values together to increment or decrement. statsCounter

[amp127]

I'm tracking 15 different things for each org and often will increment or decrement multiple values within one mutation. The current use doesn't scale great, especially when you need sharding. A Stats like mode would be great.

In the ideal state this would be most helpful:
const statsForOrg = statsCounter.for("w57tj7fretc11ct91frbqwf2qh721exr");
await statsForOrg.inc(ctx, 'views'); // increment
await statsForOrg.dec(ctx, 'spentTokens'); // decrement
await statsForOrg.add(ctx, 'rank', 5); // add 5
await statsForOrg.subtract(ctx, 'tokens' , 2); // subtract 2
await statsForOrg.getAll(ctx)
await statsForOrg.estimateCounts(ctx, "w57tj7fretc11ct91frbqwf2qh721exr")
await statsForOrg.rebalance(ctx, "w57tj7fretc11ct91frbqwf2qh721exr");

however having the value support a string or v.any would allow for similar manual programming of this.

[tomredman]

100% would use this. I'm currently creating a counter for each metrics I'm tracking, and then each of those counters per campaignId:

app.use(shardedCounter, { name: "sentCampaignCounters" });
app.use(shardedCounter, { name: "openedCampaignCounters" });
app.use(shardedCounter, { name: "deliveredCampaignCounters" });
app.use(shardedCounter, { name: "clickedCampaignCounters" });
app.use(shardedCounter, { name: "bouncedCampaignCounters" });
app.use(shardedCounter, { name: "complainedCampaignCounters" });
app.use(shardedCounter, { name: "unsubscribedCampaignCounters" });
app.use(shardedCounter, { name: "deliveryDelayedCampaignCounters" });

// ...
  handler: async (ctx, args) => {
    await ctx.db.insert("emailEvents", args);
    const counter = getCounterForType(args.type);
    await counter?.for(args.campaignId).inc(ctx);
  },
});

function getCounterForType(type: string) {
  switch (type) {
    case "sent":
      return sentCampaignCounter;
    case "delivered":
      return deliveredCampaignCounter;
    case "opened":
      return openedCampaignCounter;
    case "clicked":
      return clickedCampaignCounter;
    case "bounced":
      return bouncedCampaignCounter;
    case "complained":
      return complainedCampaignCounter;
    case "unsubscribed":
      return unsubscribedCampaignCounter;
    case "delivery_delayed":
      return deliveryDelayedCampaignCounter;
  }
}

[ianmacartney]

A workaround we found was to use the workpool component to limit parallelism, then just not worry about sharding at all and just write values to a simple table, and assume metrics aren't being updated wildly fast. But this is specific to async-heavy workloads. tracking transactional live-site metrics probably wants something like requested here