This is now done via:
We no longer carry post ids in memory and the rebake task can be resumed by running posts:rebake_uncooked_posts.
One caveat here is that the resume task will not rebake posts in reverse order (i.e. the sort order will be id ascending).
So @techAPJ, if I need to trigger a rebake of every post on a Discourse install, is @pfaffman’s method the proper one to use?
If you need to rebake all posts instantly then run bundle exec rake posts:rebake.
Post.update_all("baked_version = NULL") will rebake 100 posts (by default) every 15 minutes.
Thanks, Arpit.
FYI, I encountered some performance issues with that approach, so I went with this, which alleviated the problem and resulted in the same outcome:
Post.in_batches.update_all('baked_version = NULL')
@techAPJ I have a dummy question. Where do you run this command? After entering the app?
It tells me
bash: syntax error near unexpected token ''baked_version = NULL''
./launcher enter app
rails c
Post.in_batches.update_all('baked_version = NULL')
Would the batch method be suitable for a large amount of rebakes?
2851000 / 27182220 ( 10.5%)
This our current process after starting it yesterday with the normal rebake command, it seems to tick about 1000 every 3 seconds. We are very close to the end of our import journey and testing, and I just wanted to make sure there was a more proper way to rebake a large site before we settled on this slower method.
هل يمكن لأحد أن يشرح كيف تعمل هذه النسخة من in_batches. يُفترض أنها تعيد الخبز على دفعات، ولكن من المنشورات أعلاه، يُذكر أنها تعيد الخبز افتراضيًا على دفعات من 100 كل 15 دقيقة افتراضيًا.
لدي وظيفة إعادة خبز بحجم 2 مليون وأحاول معرفة أفضل طريقة للقيام بذلك. الوظيفة ليست عاجلة، لكنني أريد التأكد من أن العمليات العادية والعمليات الإدارية (مثل النسخ الاحتياطي) لا تتأثر بوظيفة طويلة الأمد.
والآن قرأت هذا المنشور: Rebaked all my posts, but what's it doing now? والذي يخبرني أن مهمة إعادة الخبز لا تعيد خبزها فعليًا ولكنها فقط تحددها لإعادة الخبز (كيف يتم هذا التحديد؟). العملية بطيئة جدًا لدرجة أنني أجد صعوبة حقًا في تصديق أنها تستغرق وقتًا طويلاً لمجرد تحديد منشور لإعادة الخبز.
إذًا، انتقل إلى خادم أسرع.
كن ممتنًا لأنها لا ترهق موقعك. الهدف هو منع هذه العملية من استهلاك الكثير من الموارد، والحفاظ على استجابة موقعك أثناء العملية.
استشارة المصدر هي دائمًا فكرة جيدة:
بالفعل، يجب أن يكون وضع العلامات سريعًا جدًا. ويبدو أن rebake_post يقوم باستدعاء الطهي. ربما هناك بعض المهام غير المتزامنة التي تحدث كجزء من هذا أو كنتيجة له؟
نعم، بالطبع، إنها مهمة تقوم بإنشاء مجموعة من المهام
ليس الحل المثالي، ولكني وجدت طريقة أخرى!
لقد كتبت بنفسي أداة إعادة خبز أسرع بـ 1000 مرة، فبدلاً من أن تستغرق شهرًا، تستغرق بضع دقائق فقط.
سأقوم فعليًا بإعادة الخبز قبل إدخال البيانات في قاعدة البيانات مباشرةً، لذا ستختفي تكلفة إعادة الخبز في وقت إدخال البيانات في قاعدة البيانات.
أوه، حسنًا، لم أكن على علم بسياقك.
نعم، هذا مكتوب لحالة الإنتاج.
من باب الفضول، هل يمكنك مشاركة ما فعلته؟
لقد كتبت برنامجًا لفحص جميع المشاركات المستوردة للعثور على علامات التنسيق/الرموز التعبيرية التي تحتوي عليها. ثم كتبت برنامجًا آخر لخبز المشاركات الأولية إلى HTML وتحديث قاعدة البيانات مباشرة.