Schema Update not working from json_array to json with DBAL 3 #9078
Comments
|
Did you only upgrade ORM from 2.9 to 2.10 or did you also upgrade DBAL from 2.13 to 3.1? |
|
@derrabus with dbal 3.1. |
|
This is actually a DBAL issue, I'm afraid: DBAL 3 does not ship with the You need to upgrade your schema before upgrading to DBAL 3. |
|
@derrabus but should a not longer exist type just be ignored and the schema still be updated to the new schema? |
|
Yes maybe. But at the moment, the DBAL can only create schema diffs if it knows all types that are used in the current database. |
alexander-schranz
changed the title
|
Can you register the |
|
Sure there are workaround like just remove manual the |
|
I am having the same issue. This is a breaking change introduced in doctrine/orm 2.10. When its dependencies were updated to Sure this can be prevented by also adding in a top level requirement to our project for |
|
|
Let's not collect more me-toos in here. We know about it, we know the cause, we know the workarounds. If you want to contribute to the solution, please feel free comment or open a PR. To recap:
tl;dr: If you use deprecated DBAL types, don't upgrade DBAL before you have migrated away from them. This is a community driven library. If you have an idea how to create a smoother upgrade path, please open a PR to either DBAL or ORM and we discuss it. If you want to to express that this issue affects you, feel free to 👍🏻 the issue description. |
|
Would it make sense to release these changes as a new major version as well? It would seem that when dependent packages are upgraded to next major versions and when those versions are known to have breaking changes a new major version of the parent package would be warranted. When introducing dbal v3 why not also release that as orm 3? This would provide the expected manual upgrade path and continue to follow the values of semver. |
|
@chasen nice question, let me answer it 🙂 No, it would not make sense. When using I think an improvement can be made by mentioning this in the docs: https://www.doctrine-project.org/projects/doctrine-orm/en/2.10/tutorials/getting-started.html#getting-started-with-doctrine , in case some of you would be willing to improve the developer experience. |
|
Thanks @greg0ire this is what we ended up doing but it still leaves a bad taste. This feels like a poor developer experience where you had been relying on a single package previously and then a breaking change was introduced in that package without a major version change. If the issue is indeed only with DBAL and not with ORM why not remove it as a dependency then and have developers do as you suggest and explicitly add the requirement on the dbal version of their choice? Or Is that what you are recommending get updated in the getting started docs? That instead of only relying on doctrine/orm that developers also specifically define the doctrine/dbal package too? |
The ORM requires the DBAL (cannot work without it). What I'm saying is that the user should also require it if they mention it in the code they write.
Yes, as soon as you write mapping files, you depend on the DBAL, and if you use the ORM, I think you will be using mapping files. So I would expect |
|
That makes sense. Thanks for all of the explanation. If I get a few minutes later today, ill see if I can take a stab at updating the getting started docs to better call this out to help others avoid similar issues. |
As discussed in doctrine#9078 when entities utilize data mappings which are provided by the dbal lib it is expected behavior that users will explicitly define their dependency on the package.
As discussed in #9078 when entities utilize data mappings which are provided by the dbal lib it is expected behavior that users will explicitly define their dependency on the package. Co-authored-by: Grégoire Paris <postmaster@greg0ire.fr>
|
I also today reach this issue, but i fixed it using this migration: <?php declare(strict_types=1);
namespace DoctrineMigrations;
use Doctrine\DBAL\Schema\Schema;
use Doctrine\Migrations\AbstractMigration;
final class Version20220529152449 extends AbstractMigration
{
public function up(Schema $schema): void
{
$query = "
SELECT c.column_name,
pgd.description,
c.table_schema,
c.table_name
FROM pg_catalog.pg_statio_all_tables as st
inner join pg_catalog.pg_description pgd on (pgd.objoid=st.relid)
inner join information_schema.columns c on (pgd.objsubid=c.ordinal_position and c.table_schema=st.schemaname and c.table_name=st.relname)
WHERE pgd.description = :desc
";
$data = $this->connection
->executeQuery($query, ["desc" => '(DC2Type:json_array)'])
->fetchAllAssociative();
foreach ($data as $column) {
$this->addSql("
COMMENT ON COLUMN {$column['table_schema']}.{$column['table_name']}.{$column['column_name']} IS NULL;
");
}
}
public function down(Schema $schema): void
{
// no way back!
}
} |
|
I don't know if anyone still has this problem, but this solution seems to work perfectly : |
Bug Report
Summary
The deprecated json_array type is not longer supported but its actually not possible to upgrade in 2.10.0 the database from json_array to json.
Current behavior
After upgrade to doctrine/orm I did replace all
json_arraywithjsonbut when now running:The the FieldRegistry fails as the database still has the comment
(DC2Type:json_array)in it and is so mapped to the json_array type.How to reproduce
Create a Entity with
json_arrayupdate doctrine/orm to2.10.0change type fromjson_arraytojsonand run:Expected behavior
An upgrade form json_array to json should work and the doctype comment be removed by using:
The text was updated successfully, but these errors were encountered: