AbstractLogEntry - Unknown doctrine type "array"

[Kaaly]

Package

show

$ composer show --latest gedmo/doctrine-extensions
name     : gedmo/doctrine-extensions
descrip. : Doctrine behavioral extensions
keywords : Blameable, behaviors, doctrine, extensions, gedmo, loggable, nestedset, odm, orm, sluggable, sortable, timestampable, translatable, tree, uploadable
versions : * 3.17.0
released : 2024-10-06, this week
latest   : 3.17.0 released 2024-10-06, this week
type     : library
license  : MIT License (MIT) (OSI approved) https://spdx.org/licenses/MIT.html#licenseText
homepage : http://gediminasm.org/
source   : [git] https://github.com/doctrine-extensions/DoctrineExtensions.git 38b3737997ce58c1187807d18abc49d0f416b4c4
dist     : [zip] https://api.github.com/repos/doctrine-extensions/DoctrineExtensions/zipball/38b3737997ce58c1187807d18abc49d0f416b4c4 38b3737997ce58c1187807d18abc49d0f416b4c4
path     : C:\laragon\www\www.tente.local\vendor\gedmo\doctrine-extensions
names    : gedmo/doctrine-extensions

support
email : [email protected]
issues : https://github.com/doctrine-extensions/DoctrineExtensions/issues
source : https://github.com/doctrine-extensions/DoctrineExtensions/tree/3.17.0
wiki : https://github.com/Atlantic18/DoctrineExtensions/tree/main/doc

autoload
psr-4
Gedmo\ => src/

requires
behat/transliterator ^1.2
doctrine/collections ^1.2 || ^2.0
doctrine/common ^2.13 || ^3.0
doctrine/deprecations ^1.0
doctrine/event-manager ^1.2 || ^2.0
doctrine/persistence ^2.2 || ^3.0
php ^7.4 || ^8.0
psr/cache ^1 || ^2 || ^3
psr/clock ^1
symfony/cache ^5.4 || ^6.0 || ^7.0

requires (dev)
doctrine/annotations ^1.13 || ^2.0
doctrine/cache ^1.11 || ^2.0
doctrine/dbal ^3.7 || ^4.0
doctrine/doctrine-bundle ^2.3
doctrine/mongodb-odm ^2.3
doctrine/orm ^2.14.0 || ^3.0
friendsofphp/php-cs-fixer ^3.14.0
nesbot/carbon ^2.71 || ^3.0
phpstan/phpstan ^1.11
phpstan/phpstan-doctrine ^1.4
phpstan/phpstan-phpunit ^1.4
phpunit/phpunit ^9.6
rector/rector ^1.1
symfony/console ^5.4 || ^6.0 || ^7.0
symfony/doctrine-bridge ^5.4 || ^6.0 || ^7.0
symfony/phpunit-bridge ^6.0 || ^7.0
symfony/uid ^5.4 || ^6.0 || ^7.0
symfony/yaml ^5.4 || ^6.0 || ^7.0

suggests
doctrine/mongodb-odm to use the extensions with the MongoDB ODM
doctrine/orm to use the extensions with the ORM

conflicts
doctrine/annotations <1.13 || >=3.0
doctrine/dbal <3.7 || >=5.0
doctrine/mongodb-odm <2.3 || >=3.0
doctrine/orm <2.14.0 || 2.16.0 || 2.16.1 || >=4.0

Doctrine packages

show

$ composer show --latest 'doctrine/*'
Color legend:
- patch or minor release available - update recommended
- major release available - update possible
- up to date version

Direct dependencies required in composer.json:
doctrine/doctrine-migrations-bundle 3.3.1  3.3.1  Symfony DoctrineMigrationsBundle

Transitive dependencies not required in composer.json:
doctrine/cache                      2.2.0  2.2.0  PHP Doctrine Cache library is a popular cache implementation that supports many different drivers such as redis, memcache, apc, mongodb and others.
doctrine/collections                2.2.2  2.2.2  PHP Doctrine Collections library that adds additional functionality on top of PHP arrays.
doctrine/common                     3.4.4  3.4.4  PHP Doctrine Common project is a library that provides additional functionality that other Doctrine projects depend on such as better reflection support, proxies and much more.
doctrine/dbal                       4.1.1  4.1.1  Powerful PHP database abstraction layer (DBAL) with many features for database schema introspection and management.
doctrine/deprecations               1.1.3  1.1.3  A small layer on top of trigger_error(E_USER_DEPRECATED) or PSR-3 logging with options to disable all deprecations or selectively for packages.
doctrine/doctrine-bundle            2.13.0 2.13.0 Symfony DoctrineBundle
doctrine/event-manager              2.0.1  2.0.1  The Doctrine Event Manager is a simple PHP event system that was built to be used with the various Doctrine projects.
doctrine/inflector                  2.0.10 2.0.10 PHP Doctrine Inflector is a small library that can perform string manipulations with regard to upper/lowercase and singular/plural forms of words.
doctrine/instantiator               2.0.0  2.0.0  A small, lightweight utility to instantiate objects in PHP without invoking their constructors
doctrine/lexer                      3.0.1  3.0.1  PHP Doctrine Lexer parser library that can be used in Top-Down, Recursive Descent Parsers.
doctrine/migrations                 3.8.1  3.8.1  PHP Doctrine Migrations project offer additional functionality on top of the database abstraction layer (DBAL) for versioning your database schema and easily deploying changes to it. ...
doctrine/orm                        3.2.2  3.2.2  Object-Relational-Mapper for PHP
doctrine/persistence                3.3.3  3.3.3  The Doctrine Persistence project is a set of shared interfaces and functionality that the different Doctrine object mappers share.
doctrine/sql-formatter              1.5.0  1.5.0  a PHP SQL highlighting library

PHP version

$ php -v
PHP 8.3.1 (cli) (built: Dec 20 2023 14:06:10) (ZTS Visual C++ 2019 x64)

Subject

Since v3.17.0 and bump doctrine/dbal to 4.0, i got this error on doctrine : Unknown column type "array" requested. Any Doctrine type that you use has to be registered with \Doctrine\DBAL\Types\Type::addType(). You can get a list of all the known types with \Doctrine\DBAL\Types\Type::getTypesMap(). If this er ror occurs during database introspection then you might have forgotten to register all database types for a Doctrine Type. Use AbstractPlatform#registerDoctrineTypeMapping() or have your custom types implement Type#getMappedDatabaseT ypes(). If the type name is empty you might have a problem with the cache or forgot some mapping information.

[mbabker]

The Loggable extension isn't compatible with DBAL 4 right now, see https://github.com/doctrine-extensions/DoctrineExtensions/issues/2502 and https://github.com/doctrine-extensions/DoctrineExtensions/pull/2825 for the progress on that.

If you need the loggable extension, you'll need to stick with DBAL 3 for the time being (I guess you could also try copying the old array type from the DBAL 3 codebase and registering it as a custom type in your application, but that's not a great long term solution, either).

[Kaaly]

Thanks for answer.

I think README need an alert on that. Official version (no alpha or beta) is published mentionning compability with doctrine/dbal v4 which is not totally true.

I will stick to DBAL 3 then

[phansys]

I think README need an alert on that. Official version (no alpha or beta) is published mentionning compability with doctrine/dbal v4 which is not totally true.

I totally agree. See #2886.

[featuriz]

Only one change is enough. In a single file, AbstractLogEntry @ line 90 :

namespace Gedmo\Loggable\Entity\MappedSuperclass;

abstract class AbstractLogEntry implements LogEntryInterface

// at line 90
/**
     * @var array<string>|null
     */
    #[ORM\Column(type: Types::JSON, nullable: true)]
    protected $data;

[mbabker]

Changing it from an array type to a JSON type like that works if you have no intention on using the old data in that table. The two field types aren't compatible when they're transformed to a database value by the DBAL (the array type makes a VARCHAR field that stores the result of serialize(), the JSON type makes a JSON column).

[YoannChabert]

I maked a workaround too by moving the data column to a new column old_data, and adding data in json type. (Just a patch then to update data from old_data)

[anthonylex]

Is there any progress on this? I understand that the change needed will effect existing data people are using. But this issue is also causing more people to continue using it when starting new projects. Could there be a way to have the change behind a config toggle so people could opt in? And/Or bring a copy of the doctrine array type into this project as it requires it?

[antoniovj1]

@mbabker Hi! Do you need some help with this issue?

[tsiatka]

any update on this ?

[Kaaly]

Any update here ?

[Blochin]

Any update here ?

[Sakshi-G-Simform]

please merge this is possible. :( i really need it to move to doctrine orm 3X

[bagsiur]

Any updates on this? It’s been a while since the issue was reported, and the problem still persists with DBAL 4

[mbabker]

Any updates on this? It’s been a while since the issue was reported, and the problem still persists with DBAL 4

The Loggable extension cannot be made fully compatible with DBAL 4 without forcing a data migration on every user, hence https://github.com/doctrine-extensions/DoctrineExtensions/pull/2825 which is a modern take on the extension. I've done what I can with that PR, it needs testing and feedback from other users considering how big of a thing it is.

please merge this is possible. :( i really need it to move to doctrine orm 3X

This package works just fine with ORM 3.x (just ignore deprecations that come from this package's code which aren't all fixable due to it being compatible with ORM 2.x, ORM 3.x, and MongoDB ODM 2.x, which all have their own little quirks in working with the object manager and its resources). And this package generally works just fine with DBAL 4.x, minus the Loggable extension.

[fabianoroberto]

If you want to use a workaround you can use composer patch to apply #[ORM\Column(type: Types::JSON, nullable: true)] change. Use follow instructions:

1. install https://github.com/cweagans/composer-patches with composer require cweagans/composer-patches
2. create a patch file inside patches/gedmo-doctrine-extensions/abstract-log-entry-json-type.patch

abstract-log-entry-json-type.patch

3. add this inside extra section of composer.json

"extra": {
    "patches": {
        "gedmo/doctrine-extensions": {
            "Change AbstractLogEntry data column type to JSON": "patches/gedmo-doctrine-extensions/abstract-log-entry-json-type.patch"
        }
    }
}

4. run composer update gedmo/doctrine-extensions

[mbabker]

While that workaround can work, I just want to make sure it's made clear that it only works well for newer applications without existing data or you don't mind a migration which wipes out your loggable history (or doing something like renaming the existing table so the old data can live in parallel with newer entries).

For existing applications, you will run into issues with the data storage as the deprecated array type stores data as a PHP-serialized array, not JSON.

If the loggable extension using the array data type is a blocker for migrating to DBAL 4 for you, and you absolutely need to migrate forward, another possibility would be to add your own ArrayType to your application which keeps the existing data structure but leaves you needing to keep up with a custom DBAL type.

It's that data shape issue that is the reason I personally went with building a new extension, which also allows cleaning up some other internal behaviors (for an example the loggable extension stores the PHP values as-is when they get serialized, so if you're using something a package like odolbeau/phone-number-bundle and versioning phone number fields, you have serialized libphonenumber\PhoneNumber instances in the data and not the normalized string value), but that also has the cost of updating your own app code whenever it ships and dealing with a data migration if that data history is important to you.

[fabianoroberto]

Yes I agree with you, but I was in a hybrid situation:

• new application with

"doctrine/dbal": "^4.2.3",
"doctrine/doctrine-bundle": "^2.14.0",
"doctrine/doctrine-migrations-bundle": "^3.4.2",
"doctrine/orm": "^3.3.3",

• despite the configuration not using loggable

stof_doctrine_extensions:
    default_locale: it_IT
    orm:
        default:
            blameable: true
            loggable: false
            sluggable: true
            softdeleteable: true
            timestampable: true
            tree: true

when I try to generate a migration it gives me the error. Interesting approach to serialize the data in a custom way ;)

[dvdknaap]

still the same issue.

it's an easy fix to make it work: src/Loggable/Entity/MappedSuperclass/AbstractLogEntry.php: line 90 - #[ORM\Column(type: 'array', nullable: true)] line 90 + #[ORM\Column(type: 'json', nullable: true)]

[mbabker]

Like pointed out before, that fix is fine if you have no need to keep any of your existing log data; the array and JSON column types don't produce compatible data structures.

[HSken]

Like pointed out before, that fix is fine if you have no need to keep any of your existing log data; the array and JSON column types don't produce compatible data structures.

It would be great if we could at least configure or select the version for a new project. It’s a bit unfortunate that we’re forced to use older versions when starting a new project.

For now gonne give the patch method a try: https://github.com/doctrine-extensions/DoctrineExtensions/issues/2883#issuecomment-2956287922

[PapyDanone]

that fix is fine if you have no need to keep any of your existing log data

@mbabker is it still a problem if the existing array log data is converted to JSON prior to migration?