Mongoose: क्या `_id` के बिना पॉप्युलेट करना संभव है?

को निर्मित 26 दिस॰ 2014 · 82टिप्पणियाँ · स्रोत: Automattic/mongoose

मैंने एपीआई http://mongoosejs.com/docs/populate.html की जांच की और कोशिश की। ऐसा लगता है कि populate केवल विदेशी _id पर काम कर सकता है। यहां तक कि एक match विकल्प भी है, यह केवल _id क्वेरी स्थिति पर अधिक फ़िल्टरिंग स्थिति जोड़ता है। _id साथ शामिल नहीं होने वाले फ़ील्ड के साथ बस पॉप्युलेट करने का कोई तरीका नहीं है।

मेरे प्रोजेक्ट में, हम _id को ObjectId के रूप में रखते हैं और ऑटो-इंक्रीमेंट नंबर के रूप में एक और फ़ील्ड है। उदाहरण के लिए, customers मॉडल है _id वस्तु के रूप में और cuid वृद्धिशील संख्या के रूप में। अन्य संग्रह केवल cuid से _id संदर्भ में नहीं हैं।

क्या इसे अनुकूलित करने में सक्षम होना बहुत अच्छा होगा?
क्या इस सुविधा के गायब होने के कारण कोई डिज़ाइन सीमा है?

enhancement

स्रोत

mocheng

👍12

सबसे उपयोगी टिप्पणी

@rturk मुझे वास्तव में वह प्लगइन पसंद है, इसे इंगित करने के लिए धन्यवाद। @alexmingoia आपके विचार फिर से क्या हैं: अपने मॉड्यूल को नेवला कोर में विलय करना? अधिक सामान्य आबादी को संभालने के लिए वर्चुअल का उपयोग करने का विचार वास्तव में शक्तिशाली है।

vkarpov15 18 फ़र॰ 2016

🎉5

सभी 82 टिप्पणियाँ

इसे अनुकूलित करने में सक्षम होना बहुत अच्छा होगा, लेकिन अभी हम _id । मैं अपने सिर के ऊपर से एक अच्छे कारण के बारे में नहीं सोच सकता, हालांकि क्यों नहीं। मुझे आगे की जांच करनी होगी।

vkarpov15 1 जन॰ 2015

न केवल एक अन्य क्षेत्र पर बल्कि खेतों के एक सेट पर भी आबादी को ठीक से समर्थन देने के लिए लगभग आवश्यक है, जो हमारे लिए एक बड़ा उपयोग मामला है।

उदाहरण के लिए, हमारे पास एक संग्रह "छात्र" है जिसमें "सदस्यता" के लिए एक शार्प कुंजी हो सकती है; जब हम अपने अनुभाग मॉडल (जिसमें छात्रों की एक सरणी होती है) से छात्र डेटा को पॉप्युलेट करते हैं, तो हमारे पास दस्तावेज़ पर सदस्यता होती है, लेकिन यह केवल "छात्र" में संग्रहीत _id के आधार पर दिखाई देगा, बजाय इसके कि हमें यह निर्दिष्ट करने की अनुमति दी जाए कि इसे मैप भी करना चाहिए दस्तावेज़ "असाइनमेंट" फ़ील्ड छात्र पर "असाइनमेंट" के लिए।

चूँकि हम तब शार्प की के बिना लुकअप कर रहे होंगे, जब पॉप्युलेट करते समय यह शार्डिंग को बेकार कर देता है, तो केवल एक के बजाय डेटा को पुनः प्राप्त करने के लिए सभी शार्क को हिट करने की आवश्यकता होती है।

यह कुछ ऐसा है जिसके लिए हम विकास के लिए धन देने के लिए तैयार होंगे या स्वयं भी करेंगे यदि हमें कुछ मार्गदर्शन मिल सकता है कि काम कहाँ करना है। यह हमारी कंपनी (ग्रेडकैम) के लिए एक प्रमुख आवश्यकता है।

taxilian 20 फ़र॰ 2015

👍3

@taxilian क्या आप shardKey स्कीमा विकल्प सेट कर रहे हैं? AFAIK यही वह विकल्प है जिसके लिए है।

vkarpov15 20 फ़र॰ 2015

मैं वास्तव में इसे अभी तक शुरू करने के लिए आगे नहीं बढ़ा हूं क्योंकि मैं इस मुद्दे का समाधान ढूंढ रहा हूं; क्या आबादी शार्पकी को ध्यान में रखती है? मेरी समझ यह थी कि shardKey केवल अपडेट और इंसर्ट को प्रभावित करता है

taxilian 20 फ़र॰ 2015

उस क्षेत्र को निर्दिष्ट करने में सक्षम होना बहुत अच्छा होगा जिसे "इसमें शामिल होना" है, उदाहरण के लिए मैं न केवल उपयोगकर्ता आईडी (यानी _id) फ़ील्ड द्वारा बल्कि उपयोगकर्ता टाइप, उपयोगकर्ता समूह इत्यादि द्वारा भी पॉप्युलेट करने में सक्षम होना चाहता हूं।
धन्यवाद!

arliber 19 अप्रैल 2015

podoler 19 अप्रैल 2015

+1 बहुत उपयोगी होगा

nadavsinai 30 अप्रैल 2015

+1 वही!

xr 9 मई 2015

+1 इसे प्राप्त करना पसंद है

prakash122 21 मई 2015

ricolo 24 मई 2015

vlapo 4 जून 2015

key जैसे पैरामीटर जोड़कर आप जिस वैरिएबल को पॉप्युलेट करना चाहते हैं उसे चुनने में सक्षम होना विशेष रूप से अच्छा होगा:

उदाहरण के लिए यदि मेरे पास ऐसे पोस्ट थे जिन्हें मैं author और comments पैरामीटर को पॉप्युलेट करना चाहता था, लेकिन पैरामीटर जनसंख्या से पहले गैर ऑब्जेक्ट आईडी पैरामीटर (उपयोगकर्ता का उपयोगकर्ता नाम और टिप्पणियों का शीर्षक) धारण कर रहे हैं:

{
author: "user1",
comments:["comment5", "comment6"],
title:"Post1"
}

मोंगो को यह बताने के लिए "कुंजी" जैसे पैरामीटर को जोड़ने में सक्षम होना अच्छा होगा कि किस पैरामीटर को देखना है:

Posts.find().populate([{path:"author", model:"Users", key:"username"}, {path:"comments", model:"Comments", key:"title"}])

यह उपयोगकर्ता नाम द्वारा पाए गए उपयोगकर्ता के साथ author पैरामीटर भर देगा और साथ ही साथ comments पैरामीटर को उनके शीर्षक से मिली टिप्पणियों से भर देगा (मुझे पता है कि शीर्षक द्वारा टिप्पणियां थोड़ी अवास्तविक हैं, लेकिन आपको मिलता है बिंदु)।

prescottprue 8 जून 2015

apankov 10 जून 2015

marklar21 14 जुल॰ 2015

john-bower 31 जुल॰ 2015

jack-guy 10 अग॰ 2015

asafam 23 अग॰ 2015

whyhankee 25 अग॰ 2015

ArcoMul 25 अग॰ 2015

बड़ा सहमत। मुझे कस्टम जनसंख्या योजनाओं को परिभाषित करने की क्षमता पसंद आएगी। फ़ाइल पथ वाले एक या अधिक फ़ील्ड वाले किसी भी स्कीमा के लिए यह बहुत अच्छा होगा, जो स्टोरेज से पढ़ने के लिए पॉप्युलेट की अनुमति देता है।

cannonpalms 3 सित॰ 2015

raphaelokon 11 सित॰ 2015

naoxink 14 सित॰ 2015

manasb-uoe 7 अक्तू॰ 2015

Poplava 9 अक्तू॰ 2015

lfk 20 अक्तू॰ 2015

RithwikAnand 31 अक्तू॰ 2015

justvisiting 6 नव॰ 2015

kumasento 13 नव॰ 2015

BentoumiTech 14 नव॰ 2015

loris 17 नव॰ 2015

tomerb15 18 नव॰ 2015

keithl8041 20 नव॰ 2015

danielflippance 22 नव॰ 2015

prabhupadas 24 नव॰ 2015

leonardokl 17 दिस॰ 2015

robjens 18 दिस॰ 2015

beinnova 21 दिस॰ 2015

MangeshPimpalkar 24 दिस॰ 2015

roygwsidev 2 जन॰ 2016

docksteaderluke 12 जन॰ 2016

wohugb 15 जन॰ 2016

joshbeam 25 जन॰ 2016

pavan612 28 जन॰ 2016

kennethkoontz 30 जन॰ 2016

R0R0N0A 4 फ़र॰ 2016

liraniom 9 फ़र॰ 2016

Pyo25 11 फ़र॰ 2016

danilvalov 17 फ़र॰ 2016

इस कोड को आजमाएं: https://github.com/alexmingoia/mongoose-populate-virtuals।

असल में, एलेक्स के कोड को मुख्य रेपो में विलय न करने और इसे एक मुख्य विशेषता बनाने का कोई कारण?

rturk 18 फ़र॰ 2016

vkarpov15 18 फ़र॰ 2016

🎉5

यही आदर्श होगा। यह कोर में बहुत बेहतर होगा क्योंकि यह Query.prototype.populate और अन्य मुख्य कार्यक्षमता को अधिभारित करता है।

केवल एक चीज जो मुझे पुल अनुरोध बनाने से रोक रही है, वह यह है कि इसमें बहुत कम या कोई परीक्षण कवरेज नहीं है, और दस्तावेज़ीकरण की कमी है। मैं इसे कई परिदृश्यों में उत्पादन में उपयोग कर रहा हूं और यह स्थिर है, लेकिन मुझे लगता है कि अगर कोई टेस्ट सूट लिखना चाहता है तो यह कुछ मामूली मुद्दों या विशिष्टताओं को उजागर कर सकता है जिन्हें दस्तावेज करने की आवश्यकता है।

क्या कोई टेस्ट सूट से निपटने को तैयार है? यदि नहीं - मैं इसे कर सकता हूं लेकिन अगले महीने से पहले इसके उतरने की उम्मीद नहीं है।