1
0
mirror of https://github.com/Unleash/unleash.git synced 2024-11-01 19:07:38 +01:00
unleash.unleash/src/lib/db
Thomas Heartman a115f89183
feat: include segment usage in CRs when showing usage in projects and flags (#5327)
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.
2023-11-14 08:49:32 +01:00
..
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 fix: project settings flag limit not properly set (#5317) 2023-11-10 09:57:20 +00:00
public-signup-token-store.ts
reset-token-store.ts
role-store.ts
segment-store.test.ts feat: include segment usage in CRs when showing usage in projects and flags (#5327) 2023-11-14 08:49:32 +01:00
segment-store.ts feat: include segment usage in CRs when showing usage in projects and flags (#5327) 2023-11-14 08:49:32 +01:00
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