Дафпесду этот ЕФ, он как будто из беты не может выйти за 10 лет

2020 год а в еф нет deleteasync да и просто delete

Что значил нет делет?

я хз, давно не пользовал, но охотно верю

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

и после этого больше НИКОГДА

наелся с лопаты

быстрее адо.нет запустить чем всю эту поеботу

Используем еф кор в проде- все ок

в еф слишком много церемоний. Я так и не оценил пользы честно говоря

Что значил нет делет?

Где там что-то кроме RemoveRange?

Где там что-то кроме RemoveRange?

Ремув обычный

На дбсете

А зачем тебе асинк если асинк на сохранении измений есть. Там нет ио никакой, чо там асинкать? Лишний раз стейт машину увеличивать

Ремув обычный

Это который требует забрать сущность из бд, пометить ее Deleted и потом удалить? Я думал оно продвинулось куда-то со времен 12 года.

Мне надо delete from table where ...;

Мне надо delete from table where ...;

Так напиши

В чем проблема

Еф никак не исключает роу скл

@Liminiens Azure B1 норм же? 1 ядро 1.75гб рам, 10гб хдд Я просто не думаю что боту надо что-то больше чем самый нищебродный вариант

там есть ещё нищеброднее

Ну я то напишу, но ор то именно в том что базовые вещи через одно место как и раньше. Я же не оконные функции хочу)

@Liminiens Azure B1 норм же? 1 ядро 1.75гб рам, 10гб хдд Я просто не думаю что боту надо что-то больше чем самый нищебродный вариант

Да вроде норм

Ну я то напишу, но ор то именно в том что базовые вещи через одно место как и раньше. Я же не оконные функции хочу)

Лол, как раз с орм функциями он отлично справляется - у нас дддщные агрегаты через него построены

Удаление вполне делается роу скл

Квери тоже через скл

Он неторопливый? Пожалуй да

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

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

Удачи тебе агрегат нормально выразить через адонет))

Или через даппер

Нормальный закрытый агрегат с точкой входа только через корень агрегации итд

Тупо способ в ногу себе шмальнуть

Ты уводишь тему от того что в еф нет функции delete в 2020, которая бы возвращала int как количество удаленных строк. Я про другое даже не заикался изначально. Я не понимаю почему этого нет. Я же не прошу что оно умело в глобальные sysref курсоры оракла. По мне это просто рофл

Ты уводишь тему от того что в еф нет функции delete в 2020, которая бы возвращала int как количество удаленных строк. Я про другое даже не заикался изначально. Я не понимаю почему этого нет. Я же не прошу что оно умело в глобальные sysref курсоры оракла. По мне это просто рофл

Ну а я не вижу в этом проблемы. И я в отличии от тебя живу с еф в проде

Почему этого нет? Ну мб это лоу приорити

Можешь ишью создать или вопрос задать

@omgszer я потом скажу сколько бот ест

Ну а я не вижу в этом проблемы. И я в отличии от тебя живу с еф в проде

я тоже живу с еф в проде и это проблема

т.е. нет ни одного нормального дизайн решения, чтобы делать так, как делает еф

Удачи тебе агрегат нормально выразить через адонет))

регулярно выражал в проде. 6к рпс на одной СУБД держал. в чём проблема?

регулярно выражал в проде. 6к рпс на одной СУБД держал. в чём проблема?

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

Хочется оценить объём скл кода

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

да, рекурсивные CTE, графы и деревья. дальше-то что?

примера не будет из-за NDA, очевидно

примера не будет из-за NDA, очевидно

можно ж переименовать / замазать имена полей

Почему этого нет? Ну мб это лоу приорити

да ты шутишь. удалять из бд никому не надо

я тоже честно говоря ору

можно ж переименовать / замазать имена полей

мне тут кому-то что-то доказать что ли надо? не верите, your choice.

да, рекурсивные CTE, графы и деревья. дальше-то что?

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

я тоже честно говоря ору

Ты точно читал что я написал?) я не знаю причин почему этого нет

мне тут кому-то что-то доказать что ли надо? не верите, your choice.

Да мне не доказательство - я верю

то есть способы вида присоедини модель к контексту, поменяй в обжект тракере стейт модели на Делетед вызови сейв ченжес

Я хочу оценить насколько оно сложнее

это типа как дилдо в жопу вставить и говорить - удобно

в еф слишком много церемоний. Я так и не оценил пользы честно говоря

Ну как же, польза в том, чтобы писать меньше кода. Ты уменьшаешь кол-во символов и увеличиваешь кол-во магии в своей жизни. Разве не романтика?

Ну как же, польза в том, чтобы писать меньше кода. Ты уменьшаешь кол-во символов и увеличиваешь кол-во магии в своей жизни. Разве не романтика?

Ага. Очень удобно. Автонахождение ентитей по имени, автонахождение праймари ключей по имени. Автосвязывание ентитей на основе ебанутых виртуальных св-в

всё охуенно

вжух и прод потух

Ага. Очень удобно. Автонахождение ентитей по имени, автонахождение праймари ключей по имени. Автосвязывание ентитей на основе ебанутых виртуальных св-в

Опять же - мы пишем явные конфигурации с флюент синтаксисом и не пользуемся автоопределениями) Проверяем сгенеренные миграции итд

Опять же - мы пишем явные конфигурации с флюент синтаксисом и не пользуемся автоопределениями) Проверяем сгенеренные миграции итд

но потом же полюбас приходится разбираться, какой там получился сиквел, пушто запрос внезапно выполняется 30 сек

но потом же полюбас приходится разбираться, какой там получился сиквел, пушто запрос внезапно выполняется 30 сек

Мы на чтение не пользуемся еф У нас цкрс, операции записи через агрегаты и еф Чтение мы строим через даппер и скл потому что на чтение чаще всего удобно работать с табличным представлением а не объектным

Но вообще разумеется я смотрю то, что еф нагенерил при написании кода и тестов на него

Опять же - мы пишем явные конфигурации с флюент синтаксисом и не пользуемся автоопределениями) Проверяем сгенеренные миграции итд

ну тогда неясно накой нужен этот еф. линк2дб и вперде

ну тогда неясно накой нужен этот еф. линк2дб и вперде

У линк2дб с имплементацией ддд были проблемы - сходу не вспомню, но при ресерче было видно что костылить приходилось Мб сейчас что-то поменялось

Короче пацаны, я не говорю что еф идеален - у него куча минусов и он проседает по перфомансу, но говорить что им нельзя пользоваться - бред Есть задачи под которые он неплохо подходит

У нас сейчас есть ряд небольших и ненагруженных сервисов в которых он прям нормально ложится

И позволяет не переусложнять код

Офк мы выберем что-то иное для сервисов с большей нагрузкой например

@aensidhe если вдруг как-нибудь получится какой-то кусочек примера реализации доменной логики и маппинга ее на бд показать - буду благодарен. Правда интересно было бы посмотреть

ну тогда неясно накой нужен этот еф. линк2дб и вперде

говорят он не умеет в двойной лефтджоин на фарше :(

я всего лишь сказал что там в 2020 нет метода delete и надо делать это в два запроса, где первый тянет весь датасет в память

я всего лишь сказал что там в 2020 нет метода delete и надо делать это в два запроса, где первый тянет весь датасет в память

ну я выше показал черезжопный метод этого не делать

там надо просто пустую модель (но с ключом) прицепить к обжект трекеру

но это блять вырвиглазный дизайн

но это блять вырвиглазный дизайн

++

ну я выше показал черезжопный метод этого не делать

Черезжопный метод это интерполяция строк через delete from nameof(Table)

ну сырой сиквель тоже ничего

в плане может даже получшее, т.к. обжект трекер вообще паибота

Черезжопный метод это интерполяция строк через delete from nameof(Table)

У нас постгре - там неймоф не очень подойдёт)

Это решается константными именами таблицы в конфигурации

И позволяет не переусложнять код

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