IBX-6173: Added indexes to ezcontentobject_attribute and ezurl_object_link tables

[mateuszdebinski]

Question	Answer
JIRA issue	IBX-6173
Type	improvement
Target Ibexa version	v3.3
BC breaks	no

Upgrade script: https://github.com/ibexa/installer/pull/112

Checklist:

• Provided PR description.
• Tested the solution manually.
• Provided automated test coverage.
• Checked that target branch is set correctly (master for features, the oldest supported for bugs).
• Ran PHP CS Fixer for new PHP code (use $ composer fix-cs).
• Asked for a review (ping @ezsystems/engineering-team).

[alongosz]

The extensive changes to data dumps and changes here suggest that adding this index makes Content Gateway very unstable. It uncovers the known issue that comes back from time to time - gateway doesn't order fields by their position (ezcontentclass_attribute.placement).

The issue of ordering fields is resolved on API level via ContentMapper, however Handler undergoes consumption BC promise, so it should return data in the same order as well. Whether this is important issue or something we can fix as a follow up, depends on if the issue appears when using MySQL and PostgreSQL. Unfortunately on CI those tests are executed on SQLIte.

Could you please check if 776052f change causes the same issue on MySQL and/or PostgreSQL? If it does then to fix it we need to improve \eZ\Publish\Core\Persistence\Legacy\Content\Gateway\DoctrineDatabase::internalLoadContent by adding

use eZ\Publish\Core\Persistence\Legacy\Content\Type\Gateway  as TypeGateway;
use eZ\Publish\SPI\Persistence\Content\Type;
// (...)
         ->innerJoin(
                'a',
                TypeGateway::FIELD_DEFINITION_TABLE,
                'f_def',
                $expr->and(
                    $expr->eq('a.contentclassattribute_id', 'f_def.id'),
                    $expr->eq('f_def.version', $queryBuilder->createNamedParameter(Type::STATUS_DEFINED))
                )
            )
            // (...)
            ->orderBy('f_def.placement', 'ASC');

I see further updates to legacy persistence tests would be needed, so it's not a quick fix.

[mateuszdebinski]

on PostgreSQL and MySQL tests pass without changes

[alongosz]

on PostgreSQL and MySQL tests pass without changes

Ok, let's fix SQLite as a follow-up. Alternatively as that follow-up you can make sure that use cases for failing SQLite tests are already covered by the proper integration tests (they should) and drop SQLite tests, because they will be dropped eventually, once I have some time to analyze every single one of them ™️ 😉

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication