Entity Core: Перед записью проверить данные на уникальность

@skitale · Регистрация: 25.05.2012

Студворк — интернет-сервис помощи студентам

Добрый день.
Столкнулся с проблемой - хочу чтобы в таблице были только уникальные значения. Решил проверять нет ли уже такой записи в таблице. Для проверки написал расширения для класса Db. В моей БД 4 таблицы - в две из них пишу всё подряд, а в две другие - только то, чего там еще нет.
(Все четыре модели у меня реализуют пустой интерфейс IDbData. Поэтому приходится в условном операторе определять тип переданного объекта.)

Вот код:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
        static public void AddUniqueOnly(this Db db, IDbData item)
        {
                if (item.GetType() == typeof(RootCertInfo))
                {
                    var equalRecords = db.RootCertInfos.Where(x => x.Equals((RootCertInfo)item));
                    if (equalRecords.Count()!=0) // System.NullReferenceException: "Ссылка на объект не указывает на экземпляр объекта."
                    {
                        db.Add(item);
                        return;
                    }
 
                }
                if (item.GetType() == typeof(CrlUrl))
                {
                    var equalRecords = db.CrlUrls.Where(x => x.Equals((CrlUrl)item));
                    if (equalRecords.Count()!=0)
                    {
                        db.Add(item);
                        return;
                    }
                }
 
            db.Add(item);
 
        }

Код выдает ошибку: System.NullReferenceException: "Ссылка на объект не указывает на экземпляр объекта."

Пошаговый дебаг не прояснил ситуацию. Возможно я не верно понимаю принцип работы EntityFramework?
Я решил проверять объекты на равенство друг другу:

C#
1
db.RootCertInfos.Where(x => x.Equals((RootCertInfo)item))

Я думал, что при запросе к таблице БД я получу список объектов (строк), которые равны - все поля одинаковые - с переданным объектом. Но так ли это работает?

И вообще насколько это корректно? Может быть у Entity есть какой-то свой способ?

Заранее спасибо.

@skitale · 06.11.2018, 16:39 **[ТС]**

Сообщение от Usaga

Я вам рекомендую делать это самостоятельно и явно. Открыть транзакцию, проверить существование записи с определённым содержимым поля, добавить запись в контекст. После того, как наберётся N записей, "сбросить" их в базу через SaveChanges(). Будет N ходок в базу, для проверки каждой записи, но зато по фен-шую.

Вы предлагаете мне тоже самое, что я описал в первом посте этой темы.

Вы мне тогда ответили:

Сообщение от Usaga

skitale, проверять на уникальность умеют все СУБД, даже всякие SQLite и Firebird. Причём уже триста лет подряд. Это не вопрос EF'а. Навешивайте на уникальные поля индекс уникальности (это в базе делается).

Установка индекса уникальности на конкретном поле таблицы не спасает - БД возвращает ошибку, а EF в ответ на нее перестает писать в базу вообще что-либо.
Поправьте меня, если я не прав, но кажется мы ходим по кругу.

@Usaga · 06.11.2018, 16:43

skitale, нет. Я вам предлагаю не просто самому в коде проверку делать, но делать это внутри транзакции, а на полях требующих уникальности должны висеть индексы уникальности. Это сильно не тоже самое.

@skitale · 06.11.2018, 16:59 **[ТС]**

Сообщение от Usaga

Я вам предлагаю не просто самому в коде проверку делать, но делать это внутри транзакции

Поясните в чем разница, пожалуйста.

@Usaga · 06.11.2018, 17:03

skitale, разница в словах выделенных жирным текстом. Индекс уникальности ускорит (в десятки раз) поиск по полям с ним, а уникальность защитит поле от неуникального значения на уровне СУБД (если в коде ошибётесь). Транзакция заблокирует доступ к индексу параллельным транзакциям, что защитит данные на время выполнения текущей транзакции (параллельно никто не сможет запихнуть данные, чью уникальность вы только что проверили, но запись в базу ещё не совершили).

Ну и если такой подход покажет плохую производительность (и только в этом случае), то можно прибегнуть к чистому SQL.

@skitale · 06.11.2018, 17:41 **[ТС]**

Код ниже выдает ту же ошибку:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public void SendToDb(List<IDbData> dataObject)
        {
            Db db = new Db();
            foreach (IDbData item in dataObject)
            {
 
                Write($"Пишу данные в таблицу {item.GetType().ToString()}");
 
                using (var transaction = db.Database.BeginTransaction())
                {
 
                    if (item.GetType() == typeof(CrlInfo))
                    {
                        var equalRecords = db.CrlInfos.Where(x => x.UcName == ((CrlInfo)item).UcName);
                        if (equalRecords != null && equalRecords.Count() != 0)
                        {
                            db.Add(item);
                            db.SaveChanges();
                            transaction.Commit();
                        }
                        else
                        {
                            Console.WriteLine($"Запись с UCName = {((CrlInfo)item).UcName} не уникальна");
                        }
                    }
                }
            }
 
            Console.WriteLine($"Запись в базу произведена");
        }

Добавлено через 10 минут
Usaga, хоть убейте я не могу понять как предложенный вами вариант решает заявленную в теме проблему.

Индекс ускоряет поиск - прекрасно, но у меня не было проблем со скоростью поиска.
Использование транзакции предотвращает параллельную запись в базу - очень хорошо, но я пишу в базу синхронно в один поток. От кого блокировать базу?

Прежде вы говорили, что СУБД сама проверит данные на уникальность с помощью индекса - да, она проверяет, но EF не знает что с этим делать дальше и из 1500 записей записывает 12, натыкается на ошибку СУБД и дальше не пишет вообще ничего. По-моему в этом проблема, а не в скорости работы или взаимной блокировке.

Вы уже предлагали делать "неправославно":

Сообщение от Usaga

Имея такой индекс на поле таблицы (можно на разных полях) вы можете: .... Или можете на пофиг пытаться вставить запись без всяких проверок. СУБД сама выполнит проверку уникальности и если что, то выдаст вам ошибку. Второе проще, но так делать не принято)

Так вот этот вариант у меня почему-то не работает. Скорее всего дело в моих кривых руках, а как сделать правильно?
Пусть долго и неэффективно, но чтобы оно заработало в конце-концов.

@Usaga · 06.11.2018, 17:56

skitale, код отвратителен чуть более, чем полностью.

Ещё и работает он задомнаперёд: он только дубликаты пытается записать.

Если сохранить авторский стиль, то так должно быть чуть лучше:

Кликните здесь для просмотра всего текста

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public void SendToDb(IEnumerable<IDbData> dataObjects)
{
    var db = new Db();
    
    using (var transaction = new TransactionScope())
    {
        foreach (var dataObject in dataObjects)
        {
            if (dataObject is CrlInfo item)
            {
                var name = item.UcName;
 
                var hasWithSameName = db.CrlInfos.Any(x => x.UcName == name);
                if (!hasWithSameName)
                {
                    db.Add(item);
                }
            }
        }
 
        db.SaveChanges();
        transaction.Complete();
    }
}

Сообщение от skitale

Индекс ускоряет поиск - прекрасно, но у меня не было проблем со скоростью поиска.
Использование транзакции предотвращает параллельную запись в базу - очень хорошо, но я пишу в базу синхронно в один поток. От кого блокировать базу?

Сделать нормально можно сразу, а не дожидаться, когда всё начнут тормозить и данные теряться. Благо, что я не предлагаю вторую "Войну и Мир" написать, а навесить индекс на поле в базе (одна строка к скрипту создания базы) и защититься от проблем конкурентного доступа (ещё пара строк в код). Это такой труд непосильный?

Сообщение от skitale

Так вот этот вариант у меня почему-то не работает.

"Почему-то" мне ничего не говорит о том, что у вас там пошло не так.

@skitale · 06.11.2018, 18:16 **[ТС]**

Сообщение от Usaga

Сделать нормально можно сразу

Полностью согласен. Но у меня не получилось.

Сообщение от Usaga

"Почему-то" мне ничего не говорит о том, что у вас там пошло не так

Понимаю вас, но я потому и написал, что не мог найти что у меня пошло не так.

Сообщение от Usaga

код отвратителен чуть более, чем полностью. Еще и работает он задомнаперёд: он только дубликаты пытается записать.

Да, действительно - спасибо, что заметили. Видимо именно в этом и была изначально моя ошибка. Ваш код работает прекрасно - и с индексом и без. Спасибо вам за терпение. А как сделать его лучше и чем именно он отвратителен, на ваш взгляд?

@Usaga · 07.11.2018, 06:16

Сообщение от skitale

Понимаю вас, но я потому и написал, что не мог найти что у меня пошло не так.

Ну вы же как-то поняли, что код некорректный?

Ошибка на этапе компиляции? Если да, то каков её текст?

Исключение во время работы? Если да, то на какой строке, каково название исключения и текст из его свойства Message?

Код молча отрабатывает, но делает не то, что нужно? Пройдите по коду под отладчиком (debugger) шаг за шагом и посмотрите, что на самом деле делает ваш код.

Сообщение от skitale

А как сделать его лучше и чем именно он отвратителен, на ваш взгляд?

Конкретно ваш фрагмент кода:
* метод в параметрах принимает конкретный тип List<T>, хотя использует только возможности реализуемого им интерфейса IEnumerable<T>. Принимайте в параметрах настолько общие интерфейсы\классы, насколько это возможно.
* принимаемая в параметрах коллекция содержит объекты какого-то сильно общего интерфейса IDbData, реальный тип которого вы довольно кривым образом проверяете, а потом кастуете к нужному типу. В 99.9% случаев можно было сделать нормально и передавать коллекцию нужных объектов, без проверок и кастования.
* класс контекста (Db) назван безобразно. Давайте классам говорящие имена, отражающие их суть и назначение.
* Db создаётся прямо в методе. Такое допустимо только в совсем крохотных приложениях. В остальных случаях Db желательно завернуть в репозиторий (паттерн такой) и принимать в конструкторе класса, в методе которого это дело и используется. Иначе формируется очень жёсткая связь между классами.
* метод SendToDb пишет прямо в консоль. Это фу ещё хуже, чем в пункте выше. Заведите интерфейс ILogger (название на усмотрение), реализация которого и будет писать куда вам надо. Внедряйте Logger или через IoC (желательно) или через синглтон (сильно проще, чем IoC, приемлемо в небольших проектах).
* кодом вида

C#
1
2
var equalRecords = db.CrlInfos.Where(x => x.UcName == ((CrlInfo)item).UcName);
if (equalRecords != null && equalRecords.Count() != 0)

вы заставляли СУБД перебирать ВСЕ ДО ЕДИНОЙ записи в таблице и проверять их имена. Да и проверка на null тут бесполезна.
* вы на каждой итерации цикла создаёте новую транзакцию и совершаете запись в базу. Если записей не миллионы, то сильно быстрее было бы (в плане скорости работы с базой) завести одну транзакцию на весь цикл и по окончанию цикла, сохранить изменения (разом) и завершить транзакцию.

@skitale · 07.11.2018, 13:38 **[ТС]**

Usaga, огромное спасибо за развернутый ответ! Многое не понял, так что ушел читать матчасть

Добавлено через 5 минут

Сообщение от Usaga

принимаемая в параметрах коллекция содержит объекты какого-то сильно общего интерфейса IDbData, реальный тип которого вы довольно кривым образом проверяете, а потом кастуете к нужному типу. В 99.9% случаев можно было сделать нормально и передавать коллекцию нужных объектов, без проверок и кастования.

Да, согласен, что это всё как-то криво, но я решил, что это неплохое решение для того чтобы метод принимал объект любого из четырех типов модели. А как можно было сделать иначе?

@Usaga · 07.11.2018, 14:17

Сообщение от skitale

А как можно было сделать иначе?

Обобщённый репозиторий.

Новые блоги и статьи Все статьи Все блоги /
Сегодня суббота, 22.08.2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. zorxor 22.08.2026 Сегодня суббота, 22. 08. 2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. Кто Я, откуда Я пришел и куда Я иду? Эти вопросы не оставляют меня ни на секунду. Жизнь на планете Земля. . .	Жизня: рисунок укладки багажа, сделанный клодом anaschu 21.08.2026 Сделал 15 снимков, он по снимкам сделал схему.	Был там один разговор по поводу свободы в материальном мире. kumehtar 19.08.2026 Суть: рассматривается живое существо, оказавшееся внутри довольно странной системы (этого мира) и пытающееся обустроить в ней свой кусок пространства. Жизнь действительно предъявляет каждому. . .	Когда логика программы не спасает от человеческих ошибок Maks 18.08.2026 В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .
Лето уходит kumehtar 17.08.2026	Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .	Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .

@Usaga 14733 / 9507 / 1363 Регистрация: 21.01.2016 Сообщений: 35,869
	06.11.2018, 16:43
	skitale, нет. Я вам предлагаю не просто самому в коде проверку делать, но делать это внутри транзакции, а на полях требующих уникальности должны висеть индексы уникальности. Это сильно не тоже самое. 0

@Usaga 14733 / 9507 / 1363 Регистрация: 21.01.2016 Сообщений: 35,869
	06.11.2018, 17:03
	skitale, разница в словах выделенных жирным текстом. Индекс уникальности ускорит (в десятки раз) поиск по полям с ним, а уникальность защитит поле от неуникального значения на уровне СУБД (если в коде ошибётесь). Транзакция заблокирует доступ к индексу параллельным транзакциям, что защитит данные на время выполнения текущей транзакции (параллельно никто не сможет запихнуть данные, чью уникальность вы только что проверили, но запись в базу ещё не совершили). Ну и если такой подход покажет плохую производительность (и только в этом случае), то можно прибегнуть к чистому SQL. 0