वुडवर्क को देखते हुए इसे अभी के लिए टालते हुए बड़े अपडेट पर योजनाओं को अंतिम रूप दे रहा है। यदि वुडवर्क पांडा का विस्तार बन जाता है, तो हम ऐसा नहीं करना चाहते हैं या करने की आवश्यकता नहीं है।

@ Angela97lin और मैंने चेक इन किया और कुछ कार्यान्वयन विकल्पों पर चर्चा की:

1. घटक ग्राफ़ मूल्यांकन पास पांडा प्रत्येक घटक के लिए है। घटकों के लिए ww प्रकार इंगित करने के लिए, या तो fit आदि में नए फ़ील्ड जोड़ें, या प्रासंगिक कॉलम इंगित करने के लिए init पैरामीटर का उपयोग करने के टेक्स्ट फीचराइज़र पैटर्न के साथ चिपके रहें। नुकसान: एपीआई के नजरिए से बदसूरत, यही कारण है कि हमने पहली जगह में लकड़ी का काम किया।
2. घटक ग्राफ मूल्यांकन के दौरान, प्रत्येक घटक के लिए लकड़ी का काम पास करें। प्रत्येक घटक वापसी पांडा है। नुकसान: एक संभावित सीमा यह है कि घटक पंडों के प्रकार को बदलने के अलावा, इनपुट सुविधाओं के लकड़ी के प्रकार या नई उत्पन्न सुविधाओं को नहीं बदल सकते हैं। हालांकि हमारे पास कोई घटक नहीं है जो इस पर निर्भर करता है।
3. घटक ग्राफ मूल्यांकन के दौरान, प्रत्येक घटक के लिए लकड़ी का काम पास करें। प्रत्येक घटक वापस लकड़ी का काम करें। चुनौती: अधिकांश घटकों को सुविधाओं को जोड़ने, सुविधाओं को हटाने या सुविधाओं को संशोधित करने जैसे परिवर्तन करने के लिए आंतरिक रूप से पांडा में परिवर्तित होना चाहिए। उन परिवर्तनों के बाद, हमें यह सुनिश्चित करना होगा कि मूल वुडवर्क प्रकार नए लौटाए गए वुडवर्क डेटाटेबल में शामिल हो जाएं, अन्यथा उपयोगकर्ता-ओवरराइड सेटिंग्स खो जाएंगी, जैसा कि वे आज हैं।

स्थिति: @angela97lin वर्तमान में #1668 . में विकल्प 3 का अनुसरण कर रही है

योजना: हम कई ww डेटाटेबल इंस्टेंटेशन के कारण कम रनटाइम पर नज़र रखते हुए उस रणनीति को जारी रखेंगे। और हम इस पर विचार करेंगे कि क्या कोई सुविधा अनुरोध है जो हमें इसे आसान बनाने के लिए वुडवर्क से करना चाहिए। हम अब तक छूटे किसी भी सम्मोहक विकल्प पर भी नज़र रखेंगे।

@chukarsten @gsheni

ऐसा लगता है कि तीसरा विकल्प सबसे अच्छा, सबसे साफ विकल्प है। उम्मीद है कि प्रदर्शन प्रभावित नहीं होगा, लेकिन अवधारणात्मक रूप से यह ध्वनि लगता है। इसे मेरे ध्यान में लाने के लिए धन्यवाद...मेरे दिमाग को सभी चीजों के इर्द-गिर्द लपेटने की कोशिश कर रहा हूं।

इस पर हैकिंग और कुछ और सोच:

अंतिम लक्ष्य यह है कि हमें मूल तार्किक प्रकारों का ट्रैक रखने के लिए किसी तरह की आवश्यकता है जो उपयोगकर्ता चाहता है। यह घटक ग्राफ़ द्वारा रखी गई जानकारी हो सकती है, या प्रत्येक घटक के साथ पारित हो सकती है जो कुछ डेटा को बदलने के बाद उन प्रकारों को वापस सेट करने के लिए ज़िम्मेदार है। वर्तमान में 3 का पीछा कर रहा है, और घटक ग्राफ में जानकारी जोड़ रहा है क्योंकि यह परीक्षण करना सबसे आसान है (प्रत्येक घटक को अपडेट करने के बजाय) ... लेकिन घटक स्तर पर, इसका कोई मतलब नहीं होगा।

मान लें कि कोई उपयोगकर्ता वुडवर्क डेटाटेबल निर्दिष्ट करता है और स्पष्ट रूप से एक स्पष्ट कॉल को प्राकृतिक भाषा में परिवर्तित करता है। उपयोगकर्ता इसे एक घटक को पास करता है। हमें बाहरी पुस्तकालयों में जाने के लिए पांडा में बदलने की जरूरत है, और हम एक वुडवर्क ऑब्जेक्ट वापस करना चाहते हैं। यदि हम केवल एक वुडवर्क कंस्ट्रक्टर कहते हैं, तो यह केवल अनुमानित प्रकार (श्रेणीबद्ध) लेगा, जो विषम है? इसलिए हमें मूल निर्दिष्ट प्राकृतिक भाषा प्रकार का ट्रैक रखना चाहिए और उपयोगकर्ता को वापस सौंपने से पहले परिवर्तित करना चाहिए।

नोट करने के लिए दिलचस्प मानक स्केलर है: यह इंट कॉलम ले सकता है और उन्हें फ्लोट में बदल सकता है। यदि हम कॉल को मूल प्रकार (int) पर वापस सेट करने का प्रयास करते हैं, तो हम फ्लोट को int में बदलने की कोशिश करने के लिए चिल्लाएंगे जब यह सुरक्षित नहीं है। मैं

अपडेट: @dsherry और @chukarsten के साथ त्वरित चर्चा की। मैं वर्तमान में #3 लागू कर रहा हूं, लेकिन मूल उपयोगकर्ता प्रकारों का ट्रैक रखते हुए घटक ग्राफ़ हैंडल रखता हूं और उस जानकारी को अद्यतन करता हूं क्योंकि यह घटक से घटक में पारित हो जाता है। यह ठीक काम करता है और हमें उस स्थान पर ले जाता है जहां ऑटोएमएल/पाइपलाइन काम करते हैं, लेकिन #1668 विलय के बाद, हमें घटक स्तर पर इसे संभालने और घटक ग्राफ से इस कोड को हटाने से निपटना चाहिए।

मेरा अगला कार्य: मुख्य से अद्यतन शाखा से सूचकांक परीक्षण ठीक करें, टिप्पणियों और फ़ाइल मुद्दों को साफ करें जिन्हें संबोधित किया जा सकता है जो इस पीआर (केवल सामान्य सफाई कोड) से संबंधित नहीं हैं। एक बार कोड अधिक साफ हो जाने के बाद, यह देखने के लिए अतिरेक और प्रोफ़ाइल देखें कि यह बड़ा समय अंतर कहां से आ रहा है / हम इसके बारे में क्या कर सकते हैं।