Etherpad-lite: ينتج عن تصدير الوسادات المسماة * مثيل etherpad لا يستجيب

https://github.com/ether/etherpad-lite/tree/fix/export-wildcards كحل بديل. في الماضي ، قبل https://github.com/ether/etherpad-lite/commit/a0fb65205c7d7ff95f00eb9fd88e93b300f30c3d ، كان من الممكن تحديد بادئة والحصول على تصدير للوسادات المطابقة لتلك البادئة.

لفهم هذا الخطأ بشكل أفضل ، يحتاج شخص ما إلى فهم جزء منشئ الاستعلام في ueberdb.

عند استخدام خلفية sql ، فإن وجود لوحة مسماة على سبيل المثال. ___ سيتم تصدير جميع الوسادات باسم 3 أحرف.

نرى:
https://dev.mysql.com/doc/refman/5.7/en/pattern-matching.html
https://github.com/Pita/ueberDB/blob/5c2ef4dc1476ef24bc475885817816c3e602ec8b/mysql_db.js

ما الذي سيفعله ueberdb للعثور على المفتاح (* و٪ يتم تصفيتهما في etherpad المصحح ، ولكن _ هو أيضًا رمز خاص):
حدد key من store أين key مثل؟

شكرا لك! نظرًا لأن ueberdb يدعم العديد من الخلفيات الخلفية لقواعد البيانات المختلفة ، فربما نحتاج إلى التحقق منها أيضًا؟

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

سيواجه كل من sqlite و postgresql على الأقل نفس المشكلة.

لست متأكدا من الخلفيات الأخرى لقاعدة البيانات.

آسف ، الأمر يستغرق وقتًا طويلاً ...
استخدام mysql و postgresql و sqlite و crate٪ و _
كاساندرا ، أريكة ، إعادة التفكير ، مونجو ، قذرة ، redis ربما تدعم نمط PCRE regex

لا يقوم leveldb و lmdb بتطبيق findKeys

فوق؟ هذه قضية سرية خطيرة.

FWIW ، لقد قمنا بتعطيل نقطة نهاية تصدير etherpad لهذا السبب المحدد. أثناء قراءة الكود ، أدركت أن نقطة نهاية تصدير etherpad لا تستخدم padmanager مثل نقطة نهاية txt ، ولكنها تستدعي وظائف db مباشرة. سأعترف صفرًا من المعرفة بالأجزاء الداخلية لـ ethepad من هذه النقطة فصاعدًا ، ولكن نظرًا لأن نقطة نهاية txt للتصدير لا تحتوي على هذه المشكلة ، فربما يستحق الأمر تعديل نقطة نهاية etherpad لاستخدام padmanager أيضًا بدلاً من محاربة ذلك على مستوى DB؟

مرحبا،
ما هي حالة هذا الخطأ؟

أعتقد أنه يجب أيضًا إنشاء هذه المشكلة في https://github.com/Pita/ueberDB. تقوم المكتبة بتنفيذ وتصدير طرق للهروب من المشغلين اعتمادًا على قاعدة البيانات التي نعمل معها (على سبيل المثال ، يجب إفلات مشغلي regex عند العمل مع dirtydb).

https://github.com/Pita/ueberDB/issues/107

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

لذلك في رأيي ، من المنطقي تصفية جميع أحرف sql LIKE الخاصة حتى يتم إصلاح ذلك في ueberDB.

يجب إصلاحه في https://github.com/ether/etherpad-lite/commit/806c9207e365304ef0f3130d7d3ec59f362f8f9d ، لأنه لم يعد يستدعي findKeys بعد الآن. هل يمكنك تأكيد؟

مرحبًا ، نفس المشكلة ولكن مختلفة قليلاً

بمجرد أن أفتح لوحة ، تصبح العقدة جشعة للغاية بنسبة 100٪ من استخدام وحدة المعالجة المركزية ، يرجى القيام بذلك ؟؟؟؟