5.3.9 (2019-12-13)

Overview of merged pull requests

BUGFIX: Include entry removal into DB transaction during set

This makes sure all DB statements during a set() operation are in one transaction, to avoid race conditions.

Fixes #1874

  • Packages: Cache

TASK: Add a primary key to “tags” table for MySQL/MariaDB

Note: No migrations exist for the PDO cache backend!

To make sure the cache and tags tables are up-to-date, you need to remove them manually and the run the cache:setup CLI command to have them recreated with the most recent definition.

Unless you have persistent caches, that should be no problem, but give that a thought first.

The reasoning behind this change is explained in the documentation of MySQL and MariaDB.

For MySQL https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html explains:

> If the table has no PRIMARY KEY or suitable UNIQUE index, InnoDB > internally generates a hidden clustered index named GEN_CLUST_INDEX > on a synthetic column containing row ID values. The rows are ordered > by the ID that InnoDB assigns to the rows in such a table. The row > ID is a 6-byte field that increases monotonically as new rows are > inserted. Thus, the rows ordered by the row ID are physically in > insertion order.

For MariaDB it is very similar:

> In XtraDB/InnoDB tables, all indexes contain the primary key as a > suffix. Thus, when using this storage engine, keeping the primary > key as small as possible is particularly important. If a primary > key does not exist and there are no UNIQUE indexes, InnoDB creates > a 6-bytes clustered index which is invisible to the user.

(see https://mariadb.com/kb/en/library/getting-started-with-indexes/)

The bottom line is, InnoDB actually needs a PK and creates a “hidden” one, if needed. So it takes the guesswork out of the table setup, to actually define one.

Even more details can be found online in this article and it’s links: https://federico-razzoli.com/why-mysql-tables-need-a-primary-key

  • Packages: Flow

TASK: Remove code dealing with removed class/interface

The FlowSpecificBackendInterface as well as Neos\Flow\Cache\Backend are gone with Flow 5.0, so this code is never executed.

The implements CacheFactoryInterface is redundant, thus removed.

  • Packages: Flow

TASK: PHP 7.4 compatibility

Fixes #1866

  • Packages: Eel Flow

TASK: Remove version number from ext-json dependency

This has been at ^1.2 for ages, basically since Flow exists. Now, that version is really, really old (from 2006) and the package has long been moved from PECL into the PHP source (see https://pecl.php.net/package/json)

With PHP 7.4.0RC6 (at least), the version reported for ext-json is the same as the PHP version, this blocks installation via composer.

Those two facts seems to warrant a simple * for that extension dependency, like for the other PHP extensions we depend on.

  • Packages: Flow

BUGFIX: Check existence and disable new rendering limitations

The symfony/console package got new limitations for rendering the progress bar in quick succession with minor version 4.4.

We need to disable these limitations by default for now as they break our own tests.

We should think about following the defaults in the future and adjust our tests accordingly.

  • Packages: Flow

BUGFIX: Do not renew session id for sessionless tokens being authenti…

After the refactoring of #1407 not all tokens are stored in the SecurityContext, but in the Session. But only those, which do not implement SessionlessTokenInterface (which had been stored in the session before, if a session had been started). As the tokens are not longer persisted, the provider has no chance, but to authenticate the token with every request (which sounds fine and expectable for me). But if a session is started, the authentication of a session less token leads to renewal of the session id. Now in every request - which leads to rough times for concurrent requests.

This change makes sure session ids only get renewed, if the token was not sessionless.

  • Packages: Flow

Detailed log