François Ferry
May 12, 2021

CubicWeb Monthly news April 2021

During this period, we tried to fix issues, migrate some of our code base to latest version of CubicWeb. We also pursue some archeology tasks : merging or closing some merge requests from the old heads in CubicWeb's repository. We also release new version of logilab-database, RQL and CubicWeb!

CubicWeb 3.31, RQL 0.37 and logilab-database 1.18 are out!

We released Cubicweb 3.31, RQL 0.37 and logilab-database 1.18 on may 4th. The biggest change is the addition of two new RQL options: NULLSFIRST and NULLSLAST.

The NULLSFIRST and NULLSLAST options can be used to determine whether nulls appear before or after non-null values in the sort ordering. By default, null values sort as if larger than any non-null value; that is, NULLSFIRST is the default for DESC order, and NULLSLAST otherwise.

Furthermore, a lot of issues have been fixed, and a few new features have been implemented.

Here is an extract of the changelog:

  • handle same_site cookies configuration in pyramid.ini
  • rql: add support for order by NULLS LAST and NULLS FIRST
  • improve default cubicweb skeleton
  • dbcreate: don't ask confirmation to create schema in automatic
  • hooks/notification: BREAKING CHANGE correctly initialize operation with event attribute
  • RQLExpression: performance issue on RQLExpressions using EXISTS() BREAKING CHANGE: explicitly use EXISTS in RQLExpression for permissions
  • fix some security issues

One can find the full changelog on Cubicweb release page here.

Adding python types to RQL

In the past months, python types have progressively been included in RQL. This is a step forward to python types in CubicWeb itself.

A lot of work has been done, and there is still a lot of work to do. Adding types to RQL help us to simplify the refactorings. As RQL's API is not clearly defined, we will run CubicWeb's tests on each merge request of RQL, to make sure nothing breaks.

Future works

More hackathon, more developpements!

To have more time to develop CubicWeb, we will try to save a day each month to make a hackathon.

Better handling of large databases

In some CubicWeb projects, we have more and more data to manage; and databases are getting bigger and bigger. In the near future, we need to optimize the way CubicWeb deals with large databases. Table partition? More options to create indexes? We are also planning to have part of our databases checked by db experts to see what we can do.

See you next month!