[server] introduce a scheduler class to run repository "looping tasks"
We just use the sched module from the standard library and introduce a tiny
Python2/3 compatibility layer (more for convenience actually). The "looping"
aspect of tasks (previously in LoopTask class) is re-implemeted as a
`schedule_periodic_task` function. This is a reasonably thin layer as compared
to LoopTask/TasksManager classes. Only the "restart" aspect of LoopTask is no
longer present as I'm not sure it's worth keeping.
The advantage of using this (in addition to eventually dropping our custom
code) is that this scheduler class provides a `run` method that blocks the
process while running tasks in its queue. So we can rely on this to have a
'scheduler' ctl command (see forthcoming patch) that would only run "looping
tasks" without having to implement the "blocking" aspect ourself.
Related to #17057223.
3.23 (24 June 2016)
===================
New features
------------
* Python 3.x support in CubicWeb itself is now complete, except for the
twisted package (since Twisted does not completely support Python 3.x
itself). The skeleton for new cube should also be Python 3 compatible, in
particular its `setup.py` got updated.
* The `source-sync` command can now synchronize all sources in the database,
if no `<source>` argument is provided.
* Datafeed source synchronization is now asynchronous when requested from user
interface.
Database handling
~~~~~~~~~~~~~~~~~
* Most indexes and constraints will be rebuilt during the migration, because
they are now named after a md5 hash to control the name's size.
* Index are renamed upon renaming of an entity type, so they are still
correctly tracked.
* A new `db-check-index` command is added to `cubicweb-ctl`, to display the
differences between the indexes in the database and those expected by the
schema. It's recommended to run this command after the migration to 3.23 and
to adjust things manually for cases that are not easily handled by the
migration script, such as indexes of entity types that have been renamed. It
should be mostly about dropping extra indexes.
Data-import
~~~~~~~~~~~
* Deprecated `MetaGenerator` in favor of slightly adapted API in
`MetadataGenerator` (more consistent, giving more control to sub-classes and
suitable for usage with the `MassiveObjectStore`)
* Major cleanups of the `MassiveObjectStore` and its `PGHelper` companion
class:
- dropped a bunch of unnecessary / unused attributes
- refactored / renamed internal methods
- added support for a metadata generator, the now recommended way to control
metadata generation
* Deprecated `SQLGenObjectStore`, `MassiveObjectStore` should be used instead.
Backwards-incompatible changes
------------------------------
* Generative tests *à la logilab-common* are not supported anymore in
`CubicWebTC`. It is advised to use the subtests_ API (available on
`CubicWebTC` either from the standard library as of Python 3.4 or through
unittest2 package otherwise).
* `CubicWebTC`'s `set_description` method (comming from
`logilab.common.testlib.TestCase`) is no longer available.
Development
-----------
When installed within a virtualenv, CubicWeb will look for instances data as
in ``user`` mode by default, that is in ``$HOME/etc/cubicweb.d``, as opposed
to ``$VIRTUAL_ENV/etc/cubicweb.d`` previously. To restore this behavior,
explicitly set ``CW_MODE`` to ``system``. Alternatively (and preferably), the
``CW_INSTANCES_DIR`` environment variables may be used to specify instances
data location.
.. _subtests: https://docs.python.org/3/library/unittest.html#distinguishing-test-iterations-using-subtests