[views] Respond with 400 Bad Request in case of validation error in ajax request
Previously, we raised a plain RemoteCallFailed without a status code, in which
case it defaults to "500 Internal Server Error". Now, for validation
errors, we issue a 400 Bad Request since these are clearly client errors.
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