mirror of
https://github.com/Unleash/unleash.git
synced 2024-11-01 19:07:38 +01:00
a115f89183
This PR updates the segment usage counting to also include segment usage in pending change requests. The changes include: - Updating the schema to explicitly call out that change request usage is included. - Adding two tests to verify the new features - Writing an alternate query to count this data Specifically, it'll update the part of the UI that tells you how many places a segment is used: ![image](https://github.com/Unleash/unleash/assets/17786332/a77cf932-d735-4a13-ae43-a2840f7106cb) ## Implementation Implementing this was a little tricky. Previously, we'd just count distinct instances of feature names and project names on the feature_strategy table. However, to merge this with change request data, we can't just count existing usage and change request usage separately, because that could cause duplicates. Instead of turning this into a complex DB query, I've broken it up into a few separate queries and done the merging in JS. I think that's more readable and it was easier to reason about. Here's the breakdown: 1. Get the list of pending change requests. We need their IDs and their project. 2. Get the list of updateStrategy and addStrategy events that have segment data. 3. Take the result from step 2 and turn it into a dictionary of segment id to usage data. 4. Query the feature_strategy_segment and feature_strategies table, to get existing segment usage data 5. Fold that data into the change request data. 6. Perform the preexisting segment query (without counting logic) to get other segment data 7. Enrich the results of the query from step 2 with usage data. ## Discussion points I feel like this could be done in a nicer way, so any ideas on how to achieve that (whether that's as a db query or just breaking up the code differently) is very welcome. Second, using multiple queries obviously yields more overhead than just a single one. However, I do not think this is in the hot path, so I don't consider performance to be critical here, but I'm open to hearing opposing thoughts on this of course. |
||
---|---|---|
.. | ||
access-store.test.ts | ||
access-store.ts | ||
account-store.ts | ||
addon-store.ts | ||
api-token-store.ts | ||
client-applications-store.ts | ||
client-instance-store.ts | ||
client-metrics-store-v2.ts | ||
context-field-store.ts | ||
db-pool.ts | ||
db.ts | ||
environment-store.ts | ||
event-store.test.ts | ||
event-store.ts | ||
favorite-features-store.ts | ||
favorite-projects-store.ts | ||
feature-environment-store.ts | ||
feature-strategy-store.test.ts | ||
feature-tag-store.ts | ||
feature-type-store.ts | ||
group-store.ts | ||
index.ts | ||
pat-store.ts | ||
project-stats-store.ts | ||
project-store.ts | ||
public-signup-token-store.ts | ||
reset-token-store.ts | ||
role-store.ts | ||
segment-store.test.ts | ||
segment-store.ts | ||
session-store.ts | ||
setting-store.ts | ||
strategy-store.ts | ||
tag-store.ts | ||
tag-type-store.ts | ||
transaction.ts | ||
user-feedback-store.ts | ||
user-splash-store.ts | ||
user-store.ts |