BigQuery Python: پوښتنې د پراکسي له لارې کار کوي، ډاونلوډونه ناکامېږي
وګورئ چې د BigQuery Python د پایلې ډاونلوډ د پوښتنې له HTTP لارې خپلواکه د Storage API یو کلاینټ جوړوي که نه.
یوه پوښتنه کولای شي په بریالیتوب سره بشپړه شي او بیا هم د هغې پایله pandas ته د ډاونلوډ کولو پر مهال ناکامه شي. د BigQuery Python کتابتون کولای شي د دې ډاونلوډ لپاره جلا BigQuery Storage API کلاینټ وکاروي.
د RowIterator.to_dataframe انټرفیس create_bqstorage_client، چې اصلي ارزښت یې true دی، او bqstorage_client استدلال مستند کوي. هغه تنظیمات د اپلیکیشن په موجودو تړاوونو سره یوځای ولولئ. په عادي پوښتنې لاره بریالیتوب دا نه ثابتوي چې اختیاري ډاونلوډ ټرانسپورټ ورته پراکسي ملاتړ یا ترتیب لري.
| پړاو | څه باید وګورو |
|---|---|
| د اعتبارنامې ترلاسه کول | د اعتبارنامې ټرانسپورټ او د هویت endpoint |
| پوښتنه سپارل او پول کول | د BigQuery کلاینټ غوښتنې لاره |
| د Storage API له لارې ډاونلوډ | Storage API کلاینټ او د هغې ټرانسپورټ |
د کنټرول شوې پرتلې لپاره، مستند create_bqstorage_client=False انتخاب هغه اضافي کلاینټ په اتوماتيک ډول له جوړېدو ژغوري. دا کولای شي مرسته وکړي چې کومه لاره ناکامېږي. دا د فعالیت پایلو سره د ټرانسپورټ انتخاب دی، نه دا ثبوت چې پراکسي پخپله سم شوی.
که اپلیکیشن خپل Storage API کلاینټ برابروي، هغه کلاینټ په قصدي ډول ترتیب کړئ. مه انګیرئ چې بل کلاینټ ته نښلول شوی دودیز HTTP څیز هغه بیا ترتیبوي.
زاړه مثالونه د منسوخ شوي httplib2 پلي کولو یا شخصي constructor هنګونو په اړه خبرې کوي. ادغام د نصب شوي کتابتون نسل سره سم کړئ، او د ناکامۍ پړاو په راپور کې وساتئ. د DataFrame د بدلون تېروتنه او رد شوې شبکه ای اړیکه بېلابېلې پایلې دي حتی کله چې په یوه میتود غوښتنه کې واقع شي.