erp5_full_text_mroonga_catalog: Inherit priority.

Spawn fulltext indexation activity with the same priority as the
top-priority activity part of current activity group.
And expose the priority of current activity (top-priority for grouped
activities).
Ideally, the priority of each spawned activity should be the top-priority
of all activities member of this activity group for corresponding document.
But there is no obvious way to achieve that through indexation API without
increasing complexity significantly.

bt5/erp5_full_text_mroonga_catalog/CatalogMethodTemplateItem/portal_catalog/erp5_mysql_innodb/SQLCatalog_deferFullTextIndex.py

-# This script is called to defer fulltext indexing in a lower priority.
+# This script is called to defer fulltext indexing.
 METHOD_ID = script.id + 'Activity'
 GROUP_METHOD_ID = context.getPath() + '/' + METHOD_ID
 activateObject = context.getPortalObject().portal_activities.activateObject
+try:
+  priority = context.getActivityRuntimeEnvironment().getPriority()
+except KeyError:
+  # called outside of an activity, could be an immediate reindexation
+  # XXX: duplicates default priority for sake of simplicity and speed.
+  # Strictly, this could also look-up default activate parameters, but on
+  # which document ? Traversing is expensive. So keep things fast by default.
+  priority = 1
 for document, root_document_path in zip(getPath, getRootDocumentPath):
   getattr(
     activateObject(
       document,
       activity='SQLDict',
-      priority=4,
+      priority=priority,
       node='same',
       group_method_id=GROUP_METHOD_ID,
       serialization_tag='full_text_' + root_document_path,

product/CMFActivity/Activity/SQLBase.py

@@ -631,7 +631,10 @@ CREATE TABLE %s (
         method = activity_tool.invokeGroup
         args = (group_method_id, message_list, self.__class__.__name__,
                 hasattr(self, 'generateMessageUID'))
-        activity_runtime_environment = ActivityRuntimeEnvironment(None)
+        activity_runtime_environment = ActivityRuntimeEnvironment(
+          None,
+          priority=min(x.line.priority for x in message_list),
+        )
       else:
         method = activity_tool.invoke
         message, = message_list

product/CMFActivity/ActivityRuntimeEnvironment.py

@@ -41,8 +41,9 @@ class BaseMessage:
 class ActivityRuntimeEnvironment(object):
   security = ClassSecurityInfo()
 
-  def __init__(self, message):
+  def __init__(self, message, priority=None):
     self._message = message
+    self._priority = priority
 
   def __enter__(self):
     assert not hasattr(_activity_runtime_environment, 'value')
@@ -56,6 +57,13 @@ class ActivityRuntimeEnvironment(object):
   def getTag(self, default=None):
     return self._message.activity_kw.get('tag', default)
 
+  security.declarePublic('getPriority')
+  def getPriority(self):
+    result = self._priority
+    if result is None:
+      return self._message.line.priority
+    return result
+
   security.declarePublic('edit')
   def edit(self, **kw):
     # There is no point allowing to modify other attributes from a message

[Roque]

I got an error here while trying to update 2 different dev instances. I use the upgrade alarm from erp5_upgrader, and when I tried to solve the alarm to update my bts, all activities crashed due to an AttributeError in this line.

To fix it in my instances I added the AttributeError type, so this exception is catch too and the activities can be solved.

[Jérome Perrin]

I remember having same error, but because I was doing something wrong in the update.

To update we need to do something like:

1. stop all zope nodes
2. use new version of Products (by using slapos on another software release or using git command to update the working copy in parts/erp5/ )
3. make sure there are no *.pyc files in Products folders (this is important when using git in step 2)
4. start zope
5. update business templates

In my case I did not do 2 properly, so I was installing this new version of business template with an old version of product and I had this error. I restarted update by making sure zope run on the same version of products as the business templates and it was OK

[Vincent Pelletier]

The proper fix is what @jerome did. Newer BTs may depend on newer product features, so products must be upgraded first.

[Roque]

Indeed, I updated wrong my instances. Thank you @jerome and @vpelletier for the info!

[Vincent Pelletier]

If you do get any issue from upgrading products first (in this upgrade or anytime in the future), then please do report as it would be a bug.