This issue is managing implementation work around person-on-events.
Broad things to keep in mind:
We use an instance setting to decide when to use person-on-event queries.
We're going piecemeal: Get a vertical slice on prod, then continue on the rest. Trends is first.
All tests using journeys_for, or flush_person_and_events() now automatically get person properties on events. But, this doesn't matter unless we override config to use the new queries we write.
Also note: The automated CI for person-on-events disregards snapshots, since these would obviously be different. Make sure there's at least one new test to confirm that the new snapshots are correct.
Aliasing can be tricky, since there's no pdi.person_id anymore, but e.person_id instead. Remember to handle these.
... and the relevant tasks to attack: (Put an @ next to the task you pick up - they're in priority order :) )
[x] Setup CI to run all tests using the new instance setting: This ensures all old tests work with our changes. @neilkakkar
Team ingestion set up a test team (team_id 7964) with only person-on-events. We use this for all initial testing, ensuring things work, and then move on to enabling it for team 2 when the backfill is done, which will take a bit longer.
Each piece of work should be self-contained, such that enabling this setting doesn't bork other things which haven't yet been switched on. The new CI tests should automatically ensure this.
Clean up
Once this migration is over, there's a lot of things in flux that we should clean up (and think about self-hosted users upgrade path & ramifications). List of things to remove:
[ ] Aggregation by distinct IDs
[ ] Person property pushdowns
[ ] Person and distinctID joins
[ ] Group joins
[ ] Remove tests marked with TODO: Delete after
[ ] Switch the default CI tests over to person-on-events
This section is for things that came up during implementation that we need a broader discussion for
[x] Funnel Property Filters and Breakdowns can get borked when using point-in-time person properties for funnels where the first (or last) event doesn't have that property (ex: pre signup)
[x] Lifecycle query depends on person.created_at column, which isn't yet exposed on the events table. If this query ever supports groups, the same would apply to $group_X.created_at
This issue is managing implementation work around person-on-events.
Broad things to keep in mind:
journeys_for
, orflush_person_and_events()
now automatically get person properties on events. But, this doesn't matter unless we override config to use the new queries we write.pdi.person_id
anymore, bute.person_id
instead. Remember to handle these.... and the relevant tasks to attack: (Put an @ next to the task you pick up - they're in priority order :) )
Cohorts queryingThe migration plan
Team ingestion set up a test team (team_id 7964) with only person-on-events. We use this for all initial testing, ensuring things work, and then move on to enabling it for team 2 when the backfill is done, which will take a bit longer.
Each piece of work should be self-contained, such that enabling this setting doesn't bork other things which haven't yet been switched on. The new CI tests should automatically ensure this.
Clean up
Once this migration is over, there's a lot of things in flux that we should clean up (and think about self-hosted users upgrade path & ramifications). List of things to remove:
TODO: Delete after
(maybe?)remove using_person_on_events parameterProblems to address
This section is for things that came up during implementation that we need a broader discussion for
person.created_at
column, which isn't yet exposed on the events table. If this query ever supports groups, the same would apply to$group_X.created_at