Historical table for gitlab_subscriptions table
What does this MR do?
This is a database-based history log for the gitlab_subscriptions
table.
It saves the previous row in gitlab_subscriptions
into gitlab_subscriptions_histories
See Issue #13297 (moved)
Data Estimations
- On Gitlab.com we expect < 50K records per month: 5K pure updates and 20K records per month updated + rare deletions
Background
Currently our GitLab.com gitlab_subscriptions
table only captures the current state of our data. This is blocking us from doing any meaningful analysis on our subscriptions because we can only see who's subscribed right now. We have no data on who was subscribed two weeks ago or even two hours ago, all we know about is the state in this current moment.
The reasoning is because of the backend design of our application. In our database all records are overwritten to reflect the current state, which is a good design from an application point-of-view, but makes analysis of our data impossible. This "throwing out" of data is causing GitLab Inc. to miss out on capturing tons of valuable information.
For example: if a customers starts a trial on gitlab.com, we'll create a gitlab_subscriptions
record with trial=true
. If they later upgrade to a Gold plan, the existing record gets overwritten with a new record that has trial=false
. By throwing out all information about the trial ever existing, we'll never be able to measure the value or success of trials at GitLab. The exact same thing can be said about free plans, we currently have no way to see any of those conversions.
Screenshots
N/A
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team