hVosttМСУОткрой файл Extensions.cs, блондинка.
Накой мне эта поделка?
Не знаю.

hVosttСсылку на оттестированный, отлаженный и отлично рабочий NuGet-пакет я давал в этой теме. А в твоей корявой поделке даже тестов нет. Фу-фу-фу.
Чё там тестировать-то?

hVosttЧё ты опять несёшь? В SQL есть LEFT JOIN. Где аналог в LINQ?
Вот:




Это 100% аналог left join, транслируется он так же корректно.

hVosttТо, что можно сделать — ясно.
Жжешь Ты хочешь единую "оттестированную" кнопку с нугета, с надписью "сделать всё"?

hVosttТак можно и глаз через анальный проход вылечить. Ты покажи left join в LINQ, харе выпендриваться.
Если ты не умеешь готовить LINQ, то тебе и анальный проход не поможет. Инфа 147%.

hVosttМСУНе вспомню ни одного примера, где был нужен фулл. Вот кросс джойн периодически нужен.
Примеров масса.
Например?

hVosttArm79пропущено...

Дык вот же: https://msdn.microsoft.com/en-us/library/bb397895.aspx




Это не аналог left join, это способ его выполнить.
Ну это к разработчикам LINQ все вопросы. Они сделали именно так, не нравится - используй другие ORM. Хотя я не вижу проблем привыкнуть к тому, что дают разработчики платформы. Твои сопли - это унылое нытьё. Соберись, тряпка!

Arm79а вот Full - сомнительно, что провайдер настолько интеллектуальный, чтобы преобразовать в FULL OUTER JOIN комбинацию из двух LEFT + UNION
Честно говоря, нафик не нужно. Я не вспомню ни одного случая, где мы мне понадобился full join. Детские обучающие примеры и тренинг-рецептики не в счёт. И даже если понадобится full, можно просто запросить обычным запросом факты из БД и собрать full join на клиенте. Ясно, что факты - это не вся выборка из таблицы, а некая фильтрованная часть.

hVosttМСУЧё там тестировать-то?
Экстеншены. Я уже давно понял, что ты всегда избегаешь юнит-тестирования, полагаясь на своё обычное наивное «чё там тестировать-то». Ну за ето не мне тебя судить, но такие поделки — предлагай своим коллегам-студентам.
Ну протестируй экстеншены. В чем проблема? Я не понимаю проблемы, которую ты высосал из пальца. Или ты предлагаешь минимум писать код и максимум его грузить откуда-то из нугета от пионеров, которые уже протестировали свои поделки? Я правильно понял?

hVosttЭто не аналог left join. Это то, что в результате работает КАК left join, но аналогом синтаксической указанной конструкции не является.
Да, это не аналог left join, это и есть left join. Абсолютно верно. Так в чем твои страхи-то? Написать строчку кода - это проблема?

hVosttМСУЕсли ты не умеешь готовить LINQ, то тебе и анальный проход не поможет. Инфа 147%.
Тя заклинило на готовке, может ты не ту специализацию выбрал?
Пока ещё не поздно пойди работать поваром!
Меня-то не заклинило, я решаю проблемы по мере их поступления, а не несу очередную околопоносицу про какие-то жуткие страшилки о том, что нужно весь код сливать из нугета, потому что он уже протестирован.

hVosttМСУНапример?
Привёл выше.
Вот здесь может пригодиться full outer join: получить общий список владельцев (Owners) -- в левой части актуальные, в правой изменённые, пройтись по этому списку и добавить, либо удалить.
Это называется каша и в голове и в коде. Бизнес модель должна явным образом отражать данные и операцию, которую нужно с ними проделать. Вместо вываливания кашей этого в full outer join, сделай себе объект с n коллекциями и признаком, что нужно делать с этой коллекцией - добавлять, изменять, удалять. Такая модель легко тестируется и живет. Во-вторых, я так и не понял, как ты собираешься отделять в своей каше элементы, которые нужно добавить, изменить, удалять? Идея, конечно, заслуживает медали маразматика, но всё же.

hVosttМСУНу это к разработчикам LINQ все вопросы. Они сделали именно так, не нравится - используй другие ORM. Хотя я не вижу проблем привыкнуть к тому, что дают разработчики платформы. Твои сопли - это унылое нытьё. Соберись, тряпка!
Ну вот к ним и адресованы эти вопросы, что ж ты такой непонятливый. Может ты объяснишь нам, что им помешало вкорячить ключевые слова left/right/full? Поделись что ли секретом.
Так тебе дали функционал в руки, бери и пользуйся. Я не знаю, что им помешало вкорячить, но первые 2 запроса делаются элементарно из одной строчки кода. Нужность третьего практически нулевая.

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

Алексей ККакой новый тип операции в круде?
Причем тут круд?

Операции:

создать

изменить

удалить

отправить по почте

послать на х..й

убить об стену

Мало? Какой full join, зачем?

Алексей КТакая постановка задачи: изменить содержимое БД в соответствии с указанной коллекцией и фильтром по БД.
Решение: тип + сами коллекции. Или лучше всё это в base64 закодировать, а потом по magic-условиям выгребать? :)

Алексей КЭто не круд
Чегойто?

Алексей КМСУКакой full join, зачем?Да. До настоящего момента был нужен.
Хз, не понимаю его нужности применительно с данной задаче.

Алексей КМСУРешение: тип + сами коллекции.Не хочу.
Ну не хочешь называть вещи своими именами, тогда парсь, интерпретируй свои magic нуллы. Я не против. Качество такой модели уровня канализации.

Алексей КМСУИли лучше всё это в base64 закодировать, а потом по magic-условиям выгребать? :)А вы всё шутите...
А вы действительно считаете, что этот способ намного хуже интерпретации магических нулей?

Алексей КМСУпропущено...
Чегойто? В моём понимании там круд + что-то ещё.
Так. И?

Алексей КНу способ слить существующее с сохраняемым. Только я тут не при чём.
Я понимаю, это способ. Рабочий способ. По сути такой же, как и бубнотряска с base64, озвученная выше. Так? Спасибо, лесом такой магик код ))

Алексей КПро "магический нуль" до сих пор не понял.

ХвостВот здесь может пригодиться full outer join: получить общий список владельцев (Owners) -- в левой части актуальные, в правой изменённые, пройтись по этому списку и добавить, либо удалить.

Мась, а тебе отгадай, как он в full outer join'е собирается отделять мух от котлет? :)

Алексей КМСУпропущено...
Так. И? И всё!
А ничего!