Я думаю, человек имел ввиду не вложенности внутри объекта класса, а рекурсивная циклическая зависимость, такое Newtonsoft из коробки не потянет, нужно специальную опцию сериализации включать ReferenceLoopHandling.Ignore, чтобы не падал с эксэпшэном.
Я здесь говорю не про primary key, а про команду, которая должна из рандомной коллекции колонок понять где делать insert, где update, а где delete. В unique запихнуть разные колонки не получится ведь они могут быть как и null так и not null, из за чего жёсткое ограничение инструкции On conflict в postgreSql не работает.
Да в бета версии его добавили, но переход был начат на 12й версии, а сейчас ни у кого не будет времени на новые "переходы". И к сожалению Insert on conflict не смог помочь в данной ситуации. Он работает только с уникальной связкой полей, а чтобы с имитировать ms-sql'ный merge пришлось городить огромную cteшку с полем-признаком insert or update.
Мы в данный момент мигрируем с MS-SQL(T-Sql) на Pg12. И откровенно признаюсь, это просто адище в прямом смысле. Сам проект легаси, в котором накопилось бизнес логики за всё время существования (138 страдж процедур и 9 функций). И из-за этого каждый раз как в "первый раз": синтаксис отличается, очень важных языковых конструкций и команд(типа Merge) попросту нет. Запрос в Pg в отличии от T-Sql не может иметь переменных, и создание переменных типа "Table" не завезли (приходится заниматься колдунством ? с массивами собственных типов) . Даже есть ньюансы в работе одной и той же ОРМ с СУБД от мягкомягких и pg. Так что, всём желаю крепко держать "бубен" с своих руках?, он нам ещё пригодиться.
Я думаю, человек имел ввиду не вложенности внутри объекта класса, а рекурсивная циклическая зависимость, такое Newtonsoft из коробки не потянет, нужно специальную опцию сериализации включать ReferenceLoopHandling.Ignore, чтобы не падал с эксэпшэном.
Я здесь говорю не про primary key, а про команду, которая должна из рандомной коллекции колонок понять где делать insert, где update, а где delete. В unique запихнуть разные колонки не получится ведь они могут быть как и null так и not null, из за чего жёсткое ограничение инструкции On conflict в postgreSql не работает.
Да в бета версии его добавили, но переход был начат на 12й версии, а сейчас ни у кого не будет времени на новые "переходы". И к сожалению Insert on conflict не смог помочь в данной ситуации. Он работает только с уникальной связкой полей, а чтобы с имитировать ms-sql'ный merge пришлось городить огромную cteшку с полем-признаком insert or update.
Мы в данный момент мигрируем с MS-SQL(T-Sql) на Pg12. И откровенно признаюсь, это просто адище в прямом смысле. Сам проект легаси, в котором накопилось бизнес логики за всё время существования (138 страдж процедур и 9 функций). И из-за этого каждый раз как в "первый раз": синтаксис отличается, очень важных языковых конструкций и команд(типа Merge) попросту нет. Запрос в Pg в отличии от T-Sql не может иметь переменных, и создание переменных типа "Table" не завезли (приходится заниматься колдунством ? с массивами собственных типов) . Даже есть ньюансы в работе одной и той же ОРМ с СУБД от мягкомягких и pg. Так что, всём желаю крепко держать "бубен" с своих руках?, он нам ещё пригодиться.