Здравствуйте, Ikemefula, Вы писали:
I>>> Да и по возможностям как то не впечатляет EP>>Есть ли в linq2db генерация схемы (вообще, есть ли какая-нибудь схема), автоматическая миграция между разными версиями схемы? EP>>Есть ли нормальная поддержка типов/mapping'ов, а не только POCO? Наследование, абстрактные классы? I>Тут есть целый форум, можешь там спросить автора этого фремворка.
Да мне как-то всё равно — это же ты начал сравнивать количество поддерживаемых СУБД в полноценной ORM vs micro-ORM.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Да мне как-то всё равно — это же ты начал сравнивать количество поддерживаемых СУБД в полноценной ORM vs micro-ORM.
Если тебе всё равно, то зачем же ты спрашивал ? Покажи полноценный ORM на с++, посмотрим, шо в ём есть и как это сделано.
Здравствуйте, Ikemefula, Вы писали:
EP>>Да мне как-то всё равно — это же ты начал сравнивать количество поддерживаемых СУБД в полноценной ORM vs micro-ORM. I>Если тебе всё равно, то зачем же ты спрашивал ?
Ты начал мерятся количеством СУБД у решений имеющих разные весовые категории. Я тебе задал наводящие вопросы показывающие что охват возможностей совершенно разный.
I>Покажи полноценный ORM на с++, посмотрим, шо в ём есть и как это сделано.
Здравствуйте, Ikemefula, Вы писали:
I>Нужно что бы запросы были типизироваными.
И как ты это сделаешь не фиксируя связь таблицы и класса? А это совсем не всегда удобно — часто одни и те же данные хранятся в нескольких таблицах.
_>>Нуу расскажи как делается в .net маппинг в таблицу некого нашего класса. Который естественно там уже от кого-то библиотечного пронаследован и соответственно имеет набор полей, которые не надо сохранять в базу. I>POCO и в большинстве этого достаточно. Если чтото больше надо, то обычно атрибутами.
Здравствуйте, alex_public, Вы писали:
I>>Нужно что бы запросы были типизироваными.
_>И как ты это сделаешь не фиксируя связь таблицы и класса? А это совсем не всегда удобно — часто одни и те же данные хранятся в нескольких таблицах.
А я говорил что это всегда нужно ? Ты просил конкретную задачу — я дал. Если у тебя непойми что в базе, то ORM вообще не нужен.
_>>>Нуу расскажи как делается в .net маппинг в таблицу некого нашего класса. Который естественно там уже от кого-то библиотечного пронаследован и соответственно имеет набор полей, которые не надо сохранять в базу. I>>POCO и в большинстве этого достаточно. Если чтото больше надо, то обычно атрибутами.
_>Ну покажи пример то под моё описание...
Какое отношение маппинг имеет к С++ и деревьям выражений ?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Да мне как-то всё равно — это же ты начал сравнивать количество поддерживаемых СУБД в полноценной ORM vs micro-ORM. I>>Если тебе всё равно, то зачем же ты спрашивал ?
EP>Ты начал мерятся количеством СУБД у решений имеющих разные весовые категории. Я тебе задал наводящие вопросы показывающие что охват возможностей совершенно разный.
Ога. Как то выходит, что там где С++ возможностей меньше, ибо нет поддержки деревьев выражений в языке и через это получается какая то хрень.
I>>Покажи полноценный ORM на с++, посмотрим, шо в ём есть и как это сделано.
EP>http://www.youtube.com/watch?v=B1vgKT-NdRg
Здравствуйте, Ikemefula, Вы писали:
I>А я говорил что это всегда нужно ? Ты просил конкретную задачу — я дал. Если у тебя непойми что в базе, то ORM вообще не нужен.
Ты говоришь что надо чтобы все запросы всегда были типизированы. Кстати, ещё интересно как реализуются типизированные с использованием своих функций (введённых в предыдущих sql запросах)...
I>Какое отношение маппинг имеет к С++ и деревьям выражений ?
Здравствуйте, alex_public, Вы писали:
_>Ты говоришь что надо чтобы все запросы всегда были типизированы. Кстати, ещё интересно как реализуются типизированные с использованием своих функций (введённых в предыдущих sql запросах)...
I>>Какое отношение маппинг имеет к С++ и деревьям выражений ?
_>Не знаю) Это ты мне скажи http://www.rsdn.ru/forum/philosophy/5367843
Здравствуйте, Ikemefula, Вы писали:
I>Ты говорил вот что — "маппинг в таблицу некого нашего класса"
I>В задаче, которую я показал, собственно указаный маппинг это 1% от всей работы. То есть, ни о чем — OR/M это много больше чем вот этот маппинг.
Ну так покажи как на .net'e делается хотя бы этот 1% работы... )))
Здравствуйте, alex_public, Вы писали:
I>>В задаче, которую я показал, собственно указаный маппинг это 1% от всей работы. То есть, ни о чем — OR/M это много больше чем вот этот маппинг.
_>Ну так покажи как на .net'e делается хотя бы этот 1% работы... )))
Не хочу, это никак не относится к обсуждаемому вопросу
M>>Вон, ассемблер — не чета всяким Сям — забыли?
Кто тебе сказал что его забыли? Реверс-инженерия тоже не в моде?
EP>Чтобы на ассемблере обогнать результат современных C++ компиляторов, надо очень сильно постараться
Дело даже не в скорости, иногда на С/C++ (D-подавно) нельзя сделать то что можно сделать на ASM.
Прелесть С/C++ его легкость интеграции с ASM, на D такое возможно?
Здравствуйте, nen777w, Вы писали:
EP>>Чтобы на ассемблере обогнать результат современных C++ компиляторов, надо очень сильно постараться N>Дело даже не в скорости, иногда на С/C++ (D-подавно) нельзя сделать то что можно сделать на ASM.
Само собой — в abstract machine model нет прямого аналога для каждой ASM фичи.
N>Прелесть С/C++ его легкость интеграции с ASM, на D такое возможно?
Здравствуйте, IID, Вы писали:
G>>> Сейчас спектр систем, где заработает код на C#, примерно такой же, как у java и у обоих гораздо шире, чем у C++. EP>>C++ работает и на десктопах, и на планшетах, и на телефонах (разве что кроме первых версий windows phone), и на 8-битных контролерах, и даже внутри javascript IID>чойта ? Там ОС это WinCE6.0R3, которая целиком C/C++. Прикладному нейтиву вход закрыли, да. Но это искусственное ограничение, и на язык не завязанное.
Речь была именно про прикладной код. То есть что использовать для создания кросс-платформенных приложений.
Заинтесовал меня один вопрос. А почему D никак не представлено в языковой пиписькомерке The Computer Language Benchmarks Game? Казалось бы, важная составляющая в продвижении любого языка программирвоания – доказать что вот с его-то помощью код можно писать компактнее, а скорость получить не хуже чем у оппонента, а тут, такой облом-с
Здравствуйте, kaa.python, Вы писали:
KP> А почему D никак не представлено в языковой пиписькомерке
Потому что те, кто в этом напрямую заинтересован, заняты пилением компилятора. (как вариант) Фактически, "мир Ди" — это Дижиталмарс (Уолтер + Александреску) и "все остальные". Последние занимаются Ди в виде хобби, что подразумевает занятие проектами, которые нравятся лично, а не которые являются "важной составляющей продвижения".
KP> ... а тут, такой облом-с
Ну а что удивительного? Ди — язык МОЩНЫЙ и при видимой простоте, требует неслабых мозговых возможностей для правильного использования фич (как ЛИСП, например). Поэтому из тех энтузазистов, которые тратят свободное время на Ди, мало кто может заявить "я знаю Ди досконально" — соотв. никто не берётся выступать за всех на публичных ресурсах.
Вот я тоже знаю про traits, mixins, ranges, templates, но не чувствую, что могу показать код, который бы явно доказывал преимущество Ди (хотя уверен, Ди на голову превосходит существующие языки) — это надо делать Уолтеру — хотя бы на уровне одностраничных примеров.
Здравствуйте, btn1, Вы писали:
B>Ну а что удивительного? Ди — язык МОЩНЫЙ и при видимой простоте, требует неслабых мозговых возможностей для правильного использования фич (как ЛИСП, например). Поэтому из тех энтузазистов, которые тратят свободное время на Ди, мало кто может заявить "я знаю Ди досконально" — соотв. никто не берётся выступать за всех на публичных ресурсах.
Erlang знают, Clojure знаютб Haskell знают, а D нет? Мне кажется, такое предположение выглядит не очень правдоподобным и причина в чем-то другом.
Здравствуйте, kaa.python, Вы писали:
KP>Erlang знают, Clojure знаютб Haskell знают, а D нет? Мне кажется, такое предположение выглядит не очень правдоподобным и причина в чем-то другом.
Здравствуйте, btn1, Вы писали:
B>Вы не пробовали читать ВЕСЬ комментарий?
Конечно пробовал. Краткий пересказ: D офигенно мощный и сложный язык для энтузиастов и двух перцев – авторов. Он на столько мощный, что его никто не знает и не решается запилить решения для пиписькомерки.
Ну как бы такая теория не внушает доверия хотя бы потому, что он явно не более сложный, комплексный, мощный и тыды и тыпы чем Lisp (Clojure не Лисп, но один из диалектов, как никак) или Хаскель. Оба из них редки, кроме энтузиастов мало кому вперлись, но в индексе участвуют.
