Running into some trouble with `tap-zendesk` and I...
# troubleshooting
p
Running into some trouble with
tap-zendesk
and I’m not sure what the right solution is.
meltano elt tap-zendesk target-bigquery
fails with the target throwing
ValueError: 'type' or 'anyOf' are required fields in property: {}
because this field in the tickets schema is not fully defined, something
adswerve/target-bigquery
requires. However, the conversation here indicates that the field in question might not be the same type for everyone. Is the only solution here to maintain a fork of the tap?
Also, should I have posted this in #C013EKWA2Q1 instead?
t
Have you tried overriding the schema? https://meltano.com/docs/plugins.html#extractors
this is a fine channel too 🙂
p
oh that’s perfect! i didn’t know you could do that. i’ll try it out and report back, thanks!
n
If it’s helpful, I’ve also had success streamlining unnecessary fields out of tap-zendesk with that approach. The defaults there are quite permissive (more so then we needed)
p
@nick_hamlin could you explain how you’d do that? sorry i haven’t worked with jsonschemas much.
d
I remember getting around this with a custom catalog
n
@prratek_ramchandani in
meltano.yml
where I set up the config for tap-zendesk, I also added a (somewhat verbose) list of fields to select explicitly.
here’s the start of what it looks like:
Copy code
- name: tap-zendesk
    variant: singer-io
    pip_url: tap-zendesk
    config:
      start_date: redacted
      email: redacted
      api_token: redacted
      subdomain: redacted

    select:
    - organizations.created_at
    - organizations.deleted_at
    - organizations.details
    - organizations.domain_names
    - organizations.external_id
    - organizations.group_id
    - organizations.id
    - organizations.name
    - organizations.notes
    - organizations.organization_fields
    - organizations.shared_comments
    - organizations.shared_tickets
    - organizations.tags
    - organizations.updated_at
p
ah yeah that’s sorta what i was wondering, whether i’d need to throw the entire schema into
meltano.yml
. that’s helpful, thanks! following @dan_ladd’s suggestion, it seems i could override the catalog instead and provide a path to a custom catalog instead of explicitly defining the fields i want in yaml.
n
Yep, you could totally do that as well - I kinda like being able to see them all in the one place and not have to visually parse the JSONs, but the tradeoff is a pretty long yaml file