Ребят, собсно, сабж.
Есть готовый объект Person { ID = 7, ...} — вот я хочу сделать "new SqlQuery(db).Insert(person)" и чтобы ID тоже вставилось. На уровне SQL надо сделать "IDENTITY_INSERT ON", но вот как сказать тулкиту "вставляй ID тоже"?? Если просто вставлять, то сервер ругается "давай мне значение ID", потому что BLT его опускает.
Судя по ответам, проект в анабиозе.
А мне он нравится — он простой в употреблении, хотя и дико переусложнённый в плане дизайна (в угоду всемогутерности, конечно).
Так как "я и сам немного программист" , то запилил пару костылей, потому что разбираться со всеми архитектурными выкрутасами — некогда, а работу делать надо.
Кастомные сорсы закомпрессил здесь.
Итак, что появилось:
DbManager db;
db.OpenTrans("имя");// именованые транзакции
db.CloseTrans("имя");
db.CancelTrans("имя");
var qry = new SqlQuery(db);
db.SetCommand(@"SET IDENTITY_INSERT Person ON").ExecuteNonQuery();
qry.Insert(obj, true);// true = вставить запись ВМЕСТЕ С ID (identity полем)int newID = qry.InsertWithID(obj);// вставить запись и вернуть её PK (да, только целые! костыль для 99% случаев)
Никого не принуждаю, просто делюсь.
Всё руки чешутся написать свой ORM, с блэкджеком и маппингами, но пока юзаю проверенный BLT, спасибо всем авторам этого чуда!
На мой взгляд, ничего не мешает запилить MS-only ORM, зато который будет простым, легко улучшаемым(сопровождаемым) и гибким. Как показала практика использования BLT, есть много затыков при использовании тупых "объект-таблица" сопоставлений. Либа должна быть гибче в этом плане. Если прошерстить этот форум, найдётся куча неординарных, но интересных вещей. Например, ОДИН класс, который можно сохранить в несколько разных таблиц — why not? Время идёт, сценарии усложняются, EF'у этот поезд уже никогда не догнать.
Здравствуйте, Kolesiki, Вы писали:
K>Ребят, собсно, сабж. K>Есть готовый объект Person { ID = 7, ...} — вот я хочу сделать "new SqlQuery(db).Insert(person)" и чтобы ID тоже вставилось. На уровне SQL надо сделать "IDENTITY_INSERT ON", но вот как сказать тулкиту "вставляй ID тоже"?? Если просто вставлять, то сервер ругается "давай мне значение ID", потому что BLT его опускает.
Рекомендую переходить на linq2db. Там есть BulkCopy с нужными опциями. Просто, удобно и быстро.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Рекомендую переходить на linq2db
Это я давно понял, но мне что-то не понравилось в самой идее LINQ. Как в анеке:
-Ты не любишь пюрешечку?!
-Пюре я люблю, я не люблю само слово "пюрешечка"!
Я бы с куда большим удовольствием обходился без LINQ (если linq2db это позволяет). Кривой синтаксис + ограниченные возможности (по ср. с SQL) — мне эта таймбомба не нужна.
Это довольно рискованно — базировать библиотеку на сиюминутных технологиях/идеях. Тот же WPF, выворачивающий тебе локти своим MVVM — накой он мне нужен?? С LINQ — аналогично, сегодня это так или иначе пропихиваемая технология (к слову, так и не снискавшая популярности), а завтра это "пережиток прошлого" и все бежим на новую технологию ЁПРСТ.
А BLT, при всей возможной неуклюжести внутри, позволяет мне спокойно и лаконично писать всю БД-интеракцию в прозрачной форме — в нём я точно знаю, что никаких сюрпризов на сервер не отошлётся.
Не совсем понял, почему ты упомянул Рефлекшн. Он вряд ли поможет в моей задаче.
Но раз уж сказал, я заглянул. Огорчает отсутствие readme — чтобы понимать, зачем это вообще написано, поверх чего работает и где употреблять. Догадываюсь, что что-то про рантайм-генерацию типов.
Здравствуйте, Kolesiki, Вы писали:
K>Я бы с куда большим удовольствием обходился без LINQ (если linq2db это позволяет).
Да без проблем. Можно его использовать в режиме Dupper как примитивный маппер.
K>Кривой синтаксис + ограниченные возможности (по ср. с SQL) — мне эта таймбомба не нужна.
Чего?
K>Это довольно рискованно — базировать библиотеку на сиюминутных технологиях/идеях. Тот же WPF, выворачивающий тебе локти своим MVVM — накой он мне нужен?? С LINQ — аналогично, сегодня это так или иначе пропихиваемая технология (к слову, так и не снискавшая популярности), а завтра это "пережиток прошлого" и все бежим на новую технологию ЁПРСТ.
Вот ты меня сейчас прямо очень сильно огорчил своей дремучестью. Где только панахватался такой ерунды? Сиюминутной идее, как тут уже говорилось, 13 лет. LINQ в BLT/linq2db существует уже 10 лет. Технология уже давно "пропихнута" и с успехом используется понимающими разработчиками.
K>А BLT, при всей возможной неуклюжести внутри, позволяет мне спокойно и лаконично писать всю БД-интеракцию в прозрачной форме — в нём я точно знаю, что никаких сюрпризов на сервер не отошлётся.
При правильном использовании LINQ сравнивать решения на нём и чистом SQL — это примерно как сравнивать Су-57 с кукурузником. Хотя, если нужно леатать нызэнько-нызенько и не очень далеко, то сойдёт и По-2.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, IT, Вы писали:
IT>>Рекомендую переходить на linq2db
K>Это я давно понял, но мне что-то не понравилось в самой идее LINQ. Как в анеке:
K>-Ты не любишь пюрешечку?! K>-Пюре я люблю, я не люблю само слово "пюрешечка"!
K>
K>Я бы с куда большим удовольствием обходился без LINQ (если linq2db это позволяет). Кривой синтаксис + ограниченные возможности (по ср. с SQL) — мне эта таймбомба не нужна.
Ну вот опять чушь написал. С linq2db можно построить практически любой SQL на LINQ. И он гораздо лаконичней и более гибок при композиции тех же LINQ запросов. А то что на нем прототипировать проще, я вообще не упоминаю.
Вытягивай голову оттуда где она сейчас и мы тебе откроем дзен.
, то запилил пару костылей, потому что разбираться со всеми архитектурными выкрутасами — некогда, а работу делать надо.
Если нам не помогут, то мы тоже никого не пощадим.
