سؤال

أنا أستخدم ما يبدو أنه خدعة شائعة لإنشاء طريقة عرض الانضمام:

// a Customer has many Orders; show them together in one view:
function(doc) {
  if (doc.Type == "customer") {
    emit([doc._id, 0], doc);
  } else if (doc.Type == "order") {
    emit([doc.customer_id, 1], doc);
  }
}

أعلم أنني أستطيع استخدام الاستعلام التالي للحصول على واحدة customer وكل ذلك ذات صلة Orderس:

?startkey=["some_customer_id"]&endkey=["some_customer_id", 2]

ولكن الآن لقد ربطت استفسالي جدا عن كثب إلى رمز وجهة نظري. هل هناك قيمة يمكنني وضعها حيث أضع بلدي "2"لتقول أكثر بوضوح،" أريد كل شيء مرتبطة بهذا العميل "؟ أعتقد أنني رأيت

?startkey=["some_customer_id"]&endkey=["some_customer_id", {}]

لكنني لست متأكدا من ذلك {} يكون المؤكد لفرز بعد كل شيء آخر.

ائتمان cmlenz. لطريقة الانضمام.

مزيد من التوضيح من couchdb wiki صفحة على الترتيب:

الاستعلام startkey=["foo"]&endkey=["foo",{}] سوف يطابق معظم مفاتيح الصفيف مع "foo" في العنصر الأول، مثل ["foo","bar"] و ["foo",["bar","baz"]]. وبعد ومع ذلك لن تتطابق ["foo",{"an":"object"}]

وبالتالي {} يكون متأخر في ترتيب الفرز، ولكن بالتأكيد لا الاخير.

هل كانت مفيدة؟

المحلول

بدلا من محاولة العثور على أعظم قيمة ممكنة ل ثانيا عنصر في مفتاح صفيف الخاص بك، أود أن أقترح بدلا من ذلك محاولة العثور على الأقل قيمة ممكنة أكبر من أول: ?startkey=["some_customer_id"]&endkey=["some_customer_id\u0000"]&inclusive_end=false.

نصائح أخرى

لدي أفكاران.

استخدام الطوابع الزمنية

بدلا من استخدام Simple 0 و 1 لسلوك الترتيب الخاص بهم، استخدم الطابع الزمني الذي تم إنشاء السجل (على افتراض أنها جزء من السجلات) [doc._id, doc.created_at]. وبعد ثم يمكنك الاستعلام عن رأيك باستخدام StartKey لبعض التاريخ المبكر بما فيه الكفاية (من المحتمل أن يعمل Epoch)، و Endkey من "الآن"، على سبيل المثال date +%s. وبعد يجب أن يتضمن هذا النطاق الرئيسي دائما كل شيء، ولديه الاستفادة الإضافية للتوصيل حسب التاريخ، والذي ربما ما تريد على أي حال.

أو، فقط لا تقلق بشأن ذلك

يمكنك فقط فهرسة Customer_id ولا شيء أكثر. سيكون هذا ميزة لطيفة من القدرة على الاستعلام باستخدام فقط key=<customer_id>. وبعد بالتأكيد، لن يتم تجميع السجلات عندما تعود، ولكن هل هذه مشكلة للتطبيق الخاص بك؟ ما لم تكن تتوقع الكثير من السجلات، فمن المحتمل أن تكون تافهة لتفتيش العميل ببساطة من القائمة بمجرد استرداد البيانات بواسطة طلبك.

على سبيل المثال في روبي:

customer_records = records.delete_if { |record| record.type == "customer" }

على أي حال، فإن الطوابع الزمنية ربما إجابة أكثر جاذبية لحالتك.

couchdb هو في الغالب مكتوب في erlang. لا أعتقد أنه سيكون هناك حد أعلى لأحجام Tople Compounder Compound / Composite Composite غير موارد النظام (مثل المفتاح الذي تستخدمه جميع الذاكرة المتوفرة). حدود قابلية التروس Couchdb غير معروفة وفقا لموقع Couchdb. أعتقد أنه يمكنك الاستمرار في إضافة الحقول في مفتاح أساسي مركب ضخم والشيء الوحيد الذي يمنعك هو موارد النظام أو الحدود الصعبة مثل أقصى أحجام عدد صحيح في الهندسة المعمارية الهدف.

نظرا لأن CouchDB يخزن كل شيء باستخدام JSON، فمن المحتمل أن يقتصر على أكبر قيم الأرقام من قبل قياسي Ecmascript. يتم تخزين جميع الأرقام في JavaScript كقاعدة مزدوجة IEEE 754 نقطة عائمة. أعتقد أن المزدوج 64 بت تمثل القيم من - 5E-324 إلى + 1.7976931348623157E + 308.

يبدو أنه سيكون من الجيد أن يكون لديك ميزة يمكن أن تكون فيها Endkey شاملة بدلا من حصرية.

هذا ينبغي أن تفعل خدعة:

?startkey=["some_customer_id"]&endkey=["some_customer_id", "\uFFFF"]

يجب أن يشمل ذلك أي شيء يبدأ بحرف أقل من uffff (جميع أحرف Unicode)

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top