Переход с SQL Server на Aurora PostgreSQL при возникновении проблем с GUID, VARCHAR, UUID

Мне нужен совет.

Я перенес базу данных с SQL Server на Aurora PostgreSQL с помощью AWS DMS. В большинстве таблиц в SQL Server первичными ключами являются uniqueidentifier (GUID). При миграции на Postgres эти столбцы преобразуются в VARCHAR(36). Согласно документации AWS DMS, это похоже на ожидаемое.

В нашем .NET-приложении мы используем Entity Framework 6, в который я добавил новый dbContext для использования поставщика npgsql. Обратите внимание, что мы все еще сохраняем существующие поставщики EF6 для SQL Server. По сути, приложение будет использовать как SQL Server, так и PostgreSQL. Это все нормально подключено.

Когда я сталкиваюсь с некоторыми проблемами, когда мой контекст Postgres выполняет выборку в базе данных PostgreSQL, он обнаруживает множество ошибок.

Npgsql.PostgresException: 42883: оператор не существует: переменный символ = uuid

Я понимаю проблему, когда приложение, использующее EF, выполняет выборку по идентификатору (GUID), а таблица Postgres имеет идентификатор типа VARCHAR ...

Я считаю, что проблема не в приложении или EF, скорее, столбец в таблице должен быть чем-то вроде UUID. Что я могу сделать после миграции, я могу просто изменить столбец, чтобы он стал типом UUID, но так ли это и решит ли это мои проблемы? Я также чувствую, что это не может быть уникальным случаем, с которым я имею дело; кажется распространенной проблемой для всех, кто также переносит приложение .NET с SQL Server на PostgreSQL ...

Я с нетерпением жду ваших идей, комментариев, мыслей по этому поводу. Заранее спасибо.


person Steve    schedule 09.02.2021    source источник
comment
У меня никогда не было опыта работы с AWS DMS, но похоже, что миграция пошла не так, если uniqueidentifier преобразовался в varchar. Вы пробовали ALTER TABLE [table_with_guid] ALTER [guid_field] SET TYPE uuid NOT NULL?   -  person Alex Yu    schedule 09.02.2021
comment
Уверен, что миграция правильная в соответствии с документацией. См. docs.aws.amazon. com / dms / latest / userguide / При этом есть возможность создавать правила преобразования при миграции. Однако ни один из типов данных, в которые я могу преобразовать при миграции, не является UUID. См. docs.aws.amazon. ru / dms / latest / userguide /   -  person Steve    schedule 09.02.2021
comment
Ваше предложение изменить столбцы на UUID после миграции выполнимо, просто нужно сделать много таблиц, вероятно, потребуется сценарий этого ... Надеюсь, что кто-то прошел через этот опыт и как они могли преодолеть эту ситуацию ...   -  person Steve    schedule 09.02.2021
comment
Это похоже на ошибку в инструменте преобразования (по крайней мере, если значения uniqueidentifier являются действительными UUID)   -  person a_horse_with_no_name    schedule 09.02.2021


Ответы (1)


Кажется, что эта процедура миграции не совсем подходит для этой задачи, поскольку GUID (это сбивающий с толку термин Microsoft для UUID) следует перенести на uuid. Вы не только сэкономите 21 байт на каждой строке, но и не столкнетесь с этой проблемой.

Похоже, ваше приложение сравнивает значение uuid с одним из перенесенных varchar:

WHERE uniqueidentifier = UUID '87595807-3157-4a81-ac89-3e09e83c0c0a'

Вы должны добавить явное приведение, как говорится в сообщении об ошибке:

WHERE uniqueidentifier = CAST (UUID '87595807-3157-4a81-ac89-3e09e83c0c0a' AS text)

Вы бы привели к text, а не к varchar, потому что для varchar нет оператора равенства. varchar при сравнении приводится к text, потому что хранилище для этих типов идентично.

person Laurenz Albe    schedule 09.02.2021
comment
Спасибо. Да, я понимаю это (приведение uuid / text) ... Я понимаю, что если бы я использовал EF6 и npgsql, мне не пришлось бы иметь дело с такого рода манипуляциями с приведением, или, по крайней мере, с минимальным их количеством. Основываясь на ответах большинства людей, возможно, я продолжу изучение процесса миграции и посмотрю, смогу ли я перенести GUID как UUID. - person Steve; 09.02.2021
comment
Возможности ORM ограничены. - person Laurenz Albe; 09.02.2021