CRUpgradeCommandController
final class CRUpgradeCommandController extends CommandController (View source)
Provides destructive tooling to upgrade the content repository database for a new Neos release.
While there is tooling for trivial schema adjustment see "cr:setup" the addition of new db columns without defaults requires adding values inferred by the event stream which is handled by these advanced upgrades.
Also rewriting events of the DBAL event-store if deemed required is part of this upgrade tooling.
~ ~ ~ ~ ~ ~ ~
Please do ensure you have a backup of your database at hand.
~ ~ ~ ~ ~ ~ ~
By convention each upgrade specifies its release date to allow developers to determine if an upgrade is relevant.
~ ~ ~ ~ ~ ~ ~
Note regarding further event migrations
Up until the last beta 9.0.0-beta20, many migrations were provided via the "migrateevents" Flow command. They can be used to draw inspiration how to write new migrations: https://github.com/neos/neos-development-collection/blob/9.0.0-beta20/Neos.ContentRepositoryRegistry/Classes/Service/EventMigrationService.php
Properties
| protected ContentRepositoryRegistry | $contentRepositoryRegistry | ||
| protected CRUpgradeContextFactory | $upgradeContextFactory |
Methods
Optional upgrade to adjust event time stamps and node dates to UTC
Details
void
eventsRecordedAtToUtcCommand(string $contentRepository = 'default', bool $force = false)
Optional upgrade to adjust event time stamps and node dates to UTC
https://github.com/neos/neos-development-collection/pull/5716
By storing "recordedAt" as datetime field we lost its original timezone information. But we can make the assumption that its timezone should be the same as the one encoded in the ATOM metadata field "initiatingTimeStamp"
The upgrade first groups all events by the ATOM offset found in "initiatingTimeStamp". If all events are UTC "+00:00" the upgrade is not necessary. For all non UTC groups we convert the "recordedAt" datetime field to the datetime in the UTC timezone.
The upgrade must not be executed multiple times as it would remove the offset to match UTC again for the "recordedAt" datetime even if they are already meant to be UTC. To prevent this from happening we compare the "recordedAt" and "initiatingTimeStamp" and if they are equal considering timezones we know the upgrade was run.
Included in June 2026 - part of the bugfix 9.0.13, 9.1.6 and minor 9.2.0 release