Mongoose: هل يمكن الملء بدون "_id"؟

تم إنشاؤها على ٢٦ ديسمبر ٢٠١٤ · 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 ما هي أفكارك: دمج الوحدة الخاصة بك في قلب النمس؟ إن فكرة استخدام الظاهرية للتعامل مع عدد أكبر من السكان العام (بدون وجود مجال فعلي مستمر حتى db) هي فكرة قوية حقًا.

vkarpov15 في ١٨ فبراير ٢٠١٦

🎉5

ال 82 كومينتر

سيكون من الرائع أن تكون قادرًا على تخصيص هذا ، لكننا الآن نفرض _id . لا أستطيع التفكير في سبب وجيه بعيدًا عن رأسي لماذا لا. سآخذ لمزيد من التحقيق.

vkarpov15 في ١ يناير ٢٠١٥

القدرة على الملء ليس فقط في حقل واحد آخر ولكن حتى في مجموعة من الحقول مطلوبة تقريبًا لدعم التجزئة بشكل صحيح ، وهي حالة استخدام ضخمة بالنسبة لنا.

على سبيل المثال ، لدينا مجموعة "طلاب" والتي قد تحتوي على مفتاح جزء لكلمة "اشتراك" ؛ عندما نقوم بتعبئة بيانات الطلاب من نموذج الأقسام الخاص بنا (الذي يحتوي على مجموعة من الطلاب) ، يكون لدينا الاشتراك في المستند ولكن سيتم البحث فقط بناءً على _id المخزن في "الطالب" بدلاً من السماح لنا بتحديد أنه يجب أيضًا تعيين حقل "التعيين" للمستندات إلى "الواجب" على الطالب.

نظرًا لأننا سنجري بحثًا بدون مفتاح الجزء عند ملئه ، فإنه يجعل التجزئة عديمة الفائدة ، مما يتطلب ضغط جميع الأجزاء لاسترداد البيانات بدلاً من واحدة فقط.

هذا شيء نرغب في تمويل التنمية من أجله أو حتى القيام به إذا تمكنا من الحصول على بعض التوجيهات حول مكان القيام بالعمل. إنها حاجة رئيسية لشركتنا (GradeCam).

taxilian في ٢٠ فبراير ٢٠١٥

👍3

taxilian هل تقوم بتعيين خيار مخطط shardKey ؟ AFAIK هذا ما هو هذا الخيار.

vkarpov15 في ٢٠ فبراير ٢٠١٥

لم أتحرك بالفعل لبدء القيام بذلك حتى الآن لأنني كنت أبحث عن حل لهذه المشكلة ؛ هل تضع في الاعتبار shardKey؟ كنت أفهم أن ShardKey يؤثر فقط على التحديثات والإدخالات

taxilian في ٢٠ فبراير ٢٠١٥

سيكون من الرائع أن تكون قادرًا على تحديد الحقل الذي سيتم "ضمه بواسطة" ، على سبيل المثال ، أود أن أكون قادرًا على ملئه ليس فقط بواسطة حقل معرف المستخدم (أي _id) ولكن أيضًا بواسطة نوع المستخدم ، مجموعة المستخدم وما إلى ذلك.
شكرا!

arliber في ١٩ أبريل ٢٠١٥

podoler في ١٩ أبريل ٢٠١٥

1+ سيكون مفيدًا جدًا

nadavsinai في ٣٠ أبريل ٢٠١٥

+1 نفسه هنا!

xr في ٩ مايو ٢٠١٥

+1 أحب الحصول على هذا

prakash122 في ٢١ مايو ٢٠١٥

ricolo في ٢٤ مايو ٢٠١٥

vlapo في ٤ يونيو ٢٠١٥

سيكون من الجيد بشكل خاص أن تكون قادرًا على تحديد المتغير الذي ترغب في ملئه عن طريق إضافة معامل مثل key :

على سبيل المثال ، إذا كانت هناك مشاركات أرغب في ملء المعلمات author و comments من ، لكن المعلمات تحتفظ بمعلمات غير ObjectId (اسم مستخدم المستخدم وعنوان التعليقات) قبل السكان:

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

سيكون من الجيد أن تكون قادرًا على إضافة معلمة مثل "key" للسماح لـ mongo بمعرفة المعلمة التي يجب البحث عنها من خلال:

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

سيؤدي هذا إلى ملء المعلمة author بمستخدم تم العثور عليه بواسطة اسم المستخدم بالإضافة إلى ملء المعلمة comments بالتعليقات التي تم العثور عليها من خلال عنوانها (أدرك أن التعليقات حسب العنوان غير واقعية إلى حد ما ، لكنك تحصل على النقطة).

prescottprue في ٨ يونيو ٢٠١٥

apankov في ١٠ يونيو ٢٠١٥

marklar21 في ١٤ يوليو ٢٠١٥

john-bower في ٣١ يوليو ٢٠١٥

jack-guy في ١٠ أغسطس ٢٠١٥

asafam في ٢٣ أغسطس ٢٠١٥

whyhankee في ٢٥ أغسطس ٢٠١٥

ArcoMul في ٢٥ أغسطس ٢٠١٥

توافق كبير. أرغب في القدرة على تحديد مخططات السكان المخصصة. سيكون أمرًا رائعًا لأي مخطط يحتوي على حقل واحد أو أكثر يمثل مسارات ملفات ، مما يسمح بالتعبئة للقراءة من وحدة التخزين.

cannonpalms في ٣ سبتمبر ٢٠١٥

raphaelokon في ١١ سبتمبر ٢٠١٥

naoxink في ١٤ سبتمبر ٢٠١٥

manasb-uoe في ٧ أكتوبر ٢٠١٥

Poplava في ٩ أكتوبر ٢٠١٥

lfk في ٢٠ أكتوبر ٢٠١٥

RithwikAnand في ٣١ أكتوبر ٢٠١٥

justvisiting في ٦ نوفمبر ٢٠١٥

kumasento في ١٣ نوفمبر ٢٠١٥

BentoumiTech في ١٤ نوفمبر ٢٠١٥

loris في ١٧ نوفمبر ٢٠١٥

tomerb15 في ١٨ نوفمبر ٢٠١٥

keithl8041 في ٢٠ نوفمبر ٢٠١٥

danielflippance في ٢٢ نوفمبر ٢٠١٥

prabhupadas في ٢٤ نوفمبر ٢٠١٥

leonardokl في ١٧ ديسمبر ٢٠١٥

robjens في ١٨ ديسمبر ٢٠١٥

beinnova في ٢١ ديسمبر ٢٠١٥

MangeshPimpalkar في ٢٤ ديسمبر ٢٠١٥

roygwsidev في ٢ يناير ٢٠١٦

docksteaderluke في ١٢ يناير ٢٠١٦

wohugb في ١٥ يناير ٢٠١٦

joshbeam في ٢٥ يناير ٢٠١٦

pavan612 في ٢٨ يناير ٢٠١٦

kennethkoontz في ٣٠ يناير ٢٠١٦

R0R0N0A في ٤ فبراير ٢٠١٦

liraniom في ٩ فبراير ٢٠١٦

Pyo25 في ١١ فبراير ٢٠١٦

danilvalov في ١٧ فبراير ٢٠١٦

جرب هذا الكود: https://github.com/alexmingoia/mongoose-populate-virtuals.

في الواقع ، أي سبب لعدم دمج كود Alex في الريبو الرئيسي وجعل هذه الميزة الأساسية؟

rturk في ١٨ فبراير ٢٠١٦

vkarpov15 في ١٨ فبراير ٢٠١٦

🎉5

سيكون ذلك مثاليا. سيكون أفضل بكثير في جوهره لأنه يثقل كاهل Query.prototype.populate والوظائف الأساسية الأخرى.

الشيء الوحيد الذي يمنعني من إنشاء طلب سحب هو أن هناك تغطية اختبار قليلة أو معدومة ، والوثائق غير متوفرة. أنا أستخدمه في الإنتاج في سيناريوهات متعددة وهو مستقر ، لكنني أعتقد أنه إذا قام شخص ما بكتابة مجموعة اختبار ، فقد يعرض بعض المشكلات البسيطة أو الخصوصيات التي تحتاج إلى توثيق.

هل هناك شخص على استعداد للتعامل مع مجموعة الاختبار؟ إذا لم يكن الأمر كذلك - يمكنني فعل ذلك ولكن لا أتوقع أن يهبط قبل الشهر المقبل.