This partially reverts fac0ba5a

to avoid conflicts and to improve disk space efficiency.

(instead of source/destination section which was not working)

For easier debugging, so we don't have to know how python mangles
double-underscore properties, as introspection is reduced by __slots__
usage.
Suggested by Julien Muchembled <jm@nexedi.com>

So that creating an ActiveWrapper (or Method) once and reusing it to spawn
several activities gets a larger speed-up.
Message class API is not supposed to be used outside this module, so
drop failing test rather than fixing it.

Also, inherit from "object" as __slots__ are a new-style-class feature.

Also, provide one argument per line.
Also, avoid shadowing "id" built-in.

isMessageRegistered duplicates work done in registerMessage, so it wastes
time when creating an activity (in the likely event the activity is not a
duplicate).

It is (likely) already known to caller, is only used to look up an option
which is rarely enabled, and it turns out to be (relatively) expensive.

UPDATE query is exected to use the existing index on (processing_node,
priority, date) both for WHERE and ORDER BY, as is expected from
EXPLAIN-ing the equivalent SELECT:

MariaDB [erp5]> explain select uid from message_queue WHERE processing_node=0 AND date <= '2013-06-06 22:22:49' ORDER BY priority, date LIMIT 1;
+------+-------------+---------------+------+----------------------------------------------------------+-------------------------------+---------+-------+-------+--------------------------+
| id   | select_type | table         | type | possible_keys                                            | key                           | key_len | ref   | rows  | Extra                    |
+------+-------------+---------------+------+----------------------------------------------------------+-------------------------------+---------+-------+-------+--------------------------+
|    1 | SIMPLE      | message_queue | ref  | processing_node_processing,processing_node_priority_date | processing_node_priority_date | 2       | const | 26622 | Using where; Using index |
+------+-------------+---------------+------+----------------------------------------------------------+-------------------------------+---------+-------+-------+--------------------------+

If it weren't using the index for ORDER BY, "Extra" would contain
"Using filesort".

Still, UPDATE behaves differently:

  # User@Host: user[user] @  [10.0.0.3]
  # Thread_id: 1635880  Schema: erp5  QC_hit: No
  # Query_time: 2.668405  Lock_time: 2.460698  Rows_sent: 0  Rows_examined: 49263
  # Full_scan: No  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
  # Filesort: Yes  Filesort_on_disk: No  Merge_passes: 0
  SET TIMESTAMP=1370557446;
  UPDATE
    message_queue
  SET
    processing_node=12
  WHERE
    processing_node=0
    AND DATE <= '2013-06-06 22:24:04'
    ORDER BY
    priority, DATE
  LIMIT 1;

So change the UPDATE..SELECT pattern into a SELECT FOR UPDATE..UPDATE
pattern, so SELECT's correct execution plan is used.

that should be part of commit 9b5c74fb ('force' argument in
BusinessTemplate._install() should not mean clear catalog. we can and
should use 'update_catalog' argument instead to clear catalog).

we can and should use 'update_catalog' argument instead to clear catalog.

For some reason, MIN() doesn't use the index, while ORDER BY + LIMIT does.
Also, provide a more helpful error when assertion fails.

Without this, __getattr__ is executed 3 times per restricted_getattr call.
With, it's (still) called twice.

because in projects we sometimes use english translations to display a
different name to the user.

only overriding scripts or forms stay in erp5_xhtml_gadget_style and move others to erp5_xhtml_gadget_core.

before, user's input is completely ignored and calculated good values
are automatically set. and the commit fc54fbaa somehow tried to
respect user's source input, but it caused worse result for incoming
case. so this commit reverts fc54fbaa and set source and destination
just as user's input if not empty.

When starting a node, ERP5Site.__of__ calls ComponentTool.reset(), which was
never synchronised so it returned True (without generating a new cookie at its
level) and causing synchronizeDynamicModules to be called with
force=True. This generated a new cookie and leading to dynamic classes being
meaninglessly regenerated on all nodes.

Instead, modify ComponentTool.reset() behavior so it *always* reset Portal
Type classes when Components are reset (as it should have always been as the
class inheritance may have been modified) and force regeneration of Portal
Type classes in this method if reset is True.
Signed-off-by: Vincent Pelletier <vincent@nexedi.com>

When a document gets rows inserted in category table while there was none
before (typically: first document indexation), it may trigger
  IntegrityError: (1062, "Duplicate entry '...' for key 'PRIMARY'")
because in the DELETE..INSERT pattern, DELETE finds no matching rows and
does not gap-lock (because we enable innodb_locks_unsafe_for_binlog), then
the second INSERT happening, chronologically speaking, waits for the
transaction of the first to e committed, and on commit it causes such
duplicate key error.

A transient visible effect of this change is that if both competing
indexations see a different document state (because document got modified
in some 3rd transaction), the union of the resulting set of rows will be
visible until the reindexation which must have been triggered by the 3rd
transaction gets executed, at which point only the latest set will be
visible.

A similar issue exists before this change, with stricter conditions: it
needs the intersection of both sets to be empty, because a non-empty
intersection causes the duplicate key error solved here.

This change has been measured to improve scalability of an invoice building
test case (naturally triggering indexations) starting from ~12 activity
nodes:
   8 nodes:  +1.4% invoices/hour
  12 nodes:  +9.5% invoices/hour
  16 nodes: +12.3% invoices/hour
(values are the difference between DELETE..INSERT and DELETE..REPLACE)

asSQLExpression() failed when executed several times on the same instance,
because too much code was skipped when 'column_map' is cached.

Avoid getting the list twice, follow coding style, explicitly access portal
methods on portal.