BigQuery Python: gumagana ang mga query sa proxy, nabibigo ang mga download
Tingnan kung ang pag-download ng resulta ng BigQuery Python ay gumagawa ng Storage API client nang hiwalay sa HTTP path ng query.
Maaaring matagumpay na matapos ang isang query at nabibigo pa rin kapag dinodownload ang resulta nito sa pandas. Maaaring gumamit ang library ng BigQuery Python ng hiwalay na BigQuery Storage API client para sa download na iyon.
Idinodokumento ng interface na RowIterator.to_dataframe ang create_bqstorage_client, na ang default ay true, at ang argumentong bqstorage_client. Basahin ang mga setting na iyon kasama ng mga dependency na nasa application. Ang tagumpay sa karaniwang path ng query ay hindi nagpapatunay na ang opsyonal na transport ng download ay may parehong suporta sa proxy o configuration.
| Yugto | Ano ang susuriin |
|---|---|
| Pagkuha ng kredensyal | Ang transport ng kredensyal at ang endpoint ng pagkakakilanlan |
| Pagsusumite at pag-poll ng query | Ang path ng kahilingan ng BigQuery client |
| Pag-download sa pamamagitan ng Storage API | Ang Storage API client at ang transport nito |
Para sa kontroladong paghahambing, iniiwasan ng dokumentadong opsyon na create_bqstorage_client=False ang awtomatikong paggawa ng karagdagang client na iyon. Makakatulong ito na matukoy kung aling path ang nabibigo. Ito ay pagpili ng transport na may implikasyon sa performance, hindi patunay na ang proxy mismo ay naayos.
Kung ang application ay nagbibigay ng sarili nitong Storage API client, kusang i-configure ang client na iyon. Huwag ipagpalagay na ang custom na HTTP object na nakakabit sa ibang client ay muling nagko-configure nito.
Tinatalakay ng mga lumang halimbawa ang mga hindi na ginagamit na implementasyon ng httplib2 o mga pribadong hook ng constructor. Itugma ang integrasyon sa henerasyon ng naka-install na library, at panatilihin ang yugto ng pagpalya sa ulat. Ang error sa conversion ng DataFrame at ang tinanggihang koneksyon sa network ay magkaibang kinalabasan kahit nangyari sa parehong tawag ng method.