1

Можно ли сначала определить первичный ключ с учетом регистра SQL в коде структуры сущности? Я знаю, что по умолчанию SQL нечувствителен к регистру, когда дело доходит до строк, просто для того, чтобы быть ясным. Я не хочу изменять определение всей БД на регистр, чувствительный к регистру, только один столбец таблицы (первичный ключ).Определить первичный ключ таблицы SQL как чувствительный к регистру с использованием кода Entity Framework Сначала

Я получаю данные из внешнего API, который посылает данные с учетом регистра первичных ключей («а» и «A» разные записи), я знаю, что я могу изменить их и сохранить их по-разному в моей БД, но это также потребует, чтобы я был уверен в этом везде в моем коде. Это вызывающе возможно, но я бы предпочел просто избежать этого.

В идеале я надеялся найти способ определить свой первичный ключ как чувствительный к регистру через структуру сущности и не используя SQL queries.

Я был бы признателен за любые предложения или, еще лучше, простой способ сделать это.

Update

ОК, так что я довольно много потерял надежду на это время возможно, и теперь, когда я пытаюсь использовать другой подход, который:

public ovveride Up() 
{ 
    // drops the existing primary key named PK_dbo.Urls 
    Sql("ALTER TABLE dbo.Urls DROP CONSTRAINT [PK_dbo.Urls]"); 

    // change the collation 
    Sql("ALTER TABLE dbo.Urls ALTER COLUMN Url VARCHAR(10) COLLATE SQL_Latin1_General_CP1_CS_AS NOT NULL"); 

    // re-add the primary key to the Url column 
    Sql("ALTER TABLE dbo.Urls ADD CONSTRAINT [PK_dbo.ShortUrls] PRIMARY KEY (Url)"); 
} 

я не могу действительно переживают это, поскольку у меня есть 4 разных ограничения на это поле (первичный ключ + 3 других).

Я не хочу самостоятельно переписывать код ограничения. Могу ли я использовать свободный API для внесения изменений с учетом регистра?

Это автоматически сгенерированный код свободно API:

CreateTable(
       "dbo.Shapes", 
       c => new 
        { 
         TabID = c.Int(nullable: false), 
         Lbl = c.String(nullable: false, maxLength: 128), 
         wasRemoved = c.Boolean(nullable: false), 
        }) 
       .PrimaryKey(t => new { t.TabID, t.Lbl }) 
       .ForeignKey("dbo.Tabs", t => t.TabID, cascadeDelete: true) 
       .Index(t => t.TabID); 

Я был бы очень признателен решение, так как я застрял на этом на некоторое время теперь, и я ищу лучшие худшие сейчас.

Update 2

Я также нашел 2-й способ это сделать, это полностью автоматический, а после того, как вы определяете множество других вещей, так или иначе он использует аннотацию пользовательских данных. см. мой ответ ниже для получения дополнительной информации.

+0

Вы используете миграцию? – DavidG

+0

Да, что вы предлагаете? – LiranBo

ответ

1

До сих пор самое лучшее решение, которое я получил (и ни в коем случае я считаю его хорошим), является для создания SQL-скрипта с использованием EF, а затем его изменения.

Причина, по которой я это делаю, заключается в том, что значение, которое я изменяю, является не только первичным ключом, но также связано с тремя другими ограничениями.

В случае, если кто-то испытывает то же самое и просто нужен обходной путь, вы можете сделать следующее:

Сохранить SQL скрипт для нового запроса:

Update-Database -Script -SourceMigration:0 

Тогда вместо отбрасывания и добавления многие ограничения просто найдите строку, которая определяет первичный ключ, который вы хотите сделать, как чувствительны к регистру, в моем случае:

[Lbl] [nvarchar](128) NOT NULL 

изменение:

Перед тем, как вы запускаете свой сценарий, не забудьте добавить COLLATE SQL_Latin1_General_CP1_CS_AS при использовании этого в качестве внешнего ключа в других таблицах.

I не как это решение, но я использую его только потому, что это все, что у меня есть. Если у вас есть лучшее решение, отправьте его!

Решение 2

Я могу подтвердить this работы, а также, это немного из за убийство. вы определяете свою собственную аннотацию данных, здесь мы определяем пользовательский [CaseSensitive]. Работает очень хорошо, но опять-таки это действительно похоже на много ... если бы у меня не было миграции db, я бы придерживался своего первого предложения.

0

У Entity Framework нет ничего встроенного для этого - он всегда будет создавать вашу базу данных и столбцы, используя сортировку по умолчанию. Тем не менее, вы можете вручную запустить некоторые SQL в методе миграции Up() изменить параметры сортировки определенного столбца:

Sql("ALTER TABLE yourTable ALTER COLUMN YourColumn VARCHAR(50) COLLATE Latin1_General_CS_AS"); 
+0

Я ценю ваш ответ, но я уже знаю этот вариант. Это в ссылке, которую я предоставил. Я надеялся, что есть способ сделать это от EF, или творческий обходной путь, если бы этого не было. – LiranBo

+0

@ LiranBo Хм, я не читал ссылку (вероятно, должен был это сделать), но нет, нет другого способа сделать это. Ну, вы могли бы написать свой собственный пользовательский атрибут, а затем подключиться к EF, но это будет много кода. – DavidG