-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementing Person-on-Events #9802
Labels
Comments
This was referenced May 17, 2022
This was referenced May 25, 2022
Anything remaining from this list? 👀 |
Yes, all the cleanup |
This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the |
This issue was closed due to lack of activity. Feel free to reopen if it's still relevant. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
The text was updated successfully, but these errors were encountered: