You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current model (/fivetran-dbt/dbt_zendesk/models/intermediate/int_zendesk__ticket_schedules.sql) does the following to determine which schedule is first after the creation of the ticket
select
ticket.ticket_id,
ticket.created_at as schedule_created_at,
'{{default_schedule_id}}' as schedule_id
from ticket
left join ticket_schedule as first_schedule
on first_schedule.ticket_id = ticket.ticket_id
and {{ fivetran_utils.timestamp_add('second', -5, 'first_schedule.created_at') }} <= ticket.created_at
and first_schedule.created_at >= ticket.created_at
where first_schedule.ticket_id is null
But this particular join clause uses a somewhat complicated logic to ensure we are getting the first schedule created at the time the ticket is created.
and {{ fivetran_utils.timestamp_add('second', -5, 'first_schedule.created_at') }} <= ticket.created_at and first_schedule.created_at >= ticket.created_at`
Some users have noted that this logic limits it to an = operation on the where clause as DATEADD(SECOND, -5, first_schedule.created_at)>= ticket.created_at and first_schedule.created_at <= ticket.created_at becomes = ticket.created_at by simple math.
Request to explore alternate approaches to this logic, e.g., maybe a window function might be more appropriate in identifying the first ticket schedule.
Describe alternatives you've considered
No response
Are you interested in contributing this feature?
Yes.
Yes, but I will need assistance and will schedule time during your office hours for guidance.
No.
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Is there an existing feature request for this?
Describe the Feature
Current model (/fivetran-dbt/dbt_zendesk/models/intermediate/int_zendesk__ticket_schedules.sql) does the following to determine which schedule is first after the creation of the ticket
But this particular join clause uses a somewhat complicated logic to ensure we are getting the first schedule created at the time the ticket is created.
Some users have noted that this logic limits it to an = operation on the where clause as
DATEADD(SECOND, -5, first_schedule.created_at)>= ticket.created_at and first_schedule.created_at <= ticket.created_at
becomes= ticket.created_at
by simple math.Request to explore alternate approaches to this logic, e.g., maybe a window function might be more appropriate in identifying the first ticket schedule.
Describe alternatives you've considered
No response
Are you interested in contributing this feature?
Anything else?
No response
The text was updated successfully, but these errors were encountered: