ну орм то писать долго и сложно. Их пишут стаей много много лет

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

Потому что БД оперирует не теми объектами что ожидают прикладные программисты, и маппить БД невозможно никуда если не лочить её.

Всё, кончил.

Во, придумал: ОРМ это как внешнюю программу на другом языке вызывать не через биндинги, а попытавшись покрыть снаружи часть её внутрненнего кода своей логикой на своём языке.

и где-то там её приватные методы дёргать

Ну да. Так вещи в мире и работают.

Во, придумал: ОРМ это как внешнюю программу на другом языке вызывать не через биндинги, а попытавшись покрыть снаружи часть её внутрненнего кода своей логикой на своём языке.

Это ты сейчас написал компиляцию из любого языка в машинный код

https://github.com/Mihail-K/Dart смотрите какая прикольная вещь есть

Это ты сейчас написал компиляцию из любого языка в машинный код

Не понял аналогии

Вот это вот: @Table("users") @Id @AutoIncrement Сразу можно закапывать.

Ну ты пишешь программу на своем языке и потом она через костыли переводится в опкоды )

Вот это вот: @Table("users") @Id @AutoIncrement Сразу можно закапывать.

Аннотации, крутяк

Ну ты пишешь программу на своем языке и потом она через костыли переводится в опкоды )

Нет, тут 2 программы: на ди и на SQL и одна другую не вызывает как обычно а пытается понять внутреннее устройство и вызвать "за внутренности"

SQL тьюринг полный значит это возможно

Аннотации, крутяк

Это сразу расползётся по всему проекту.

Да и пусть ползёт.

Заархитектурить нужно правильно.

ну збс. оно уже неверный дизайн притащит и дублирование данных.

Откуда дублирование?

Заархитектурить нужно правильно.

невоможно это будет заархитектурить потому что там id а он скорее всего прикладному слою не нужен. Правильный путь может быть таким: по id функцией взять из БД структуру без этого id (всё равно мы его уже знаем)

Откуда дублирование?

см выше

невоможно это будет заархитектурить потому что там id а он скорее всего прикладному слою не нужен. Правильный путь может быть таким: по id функцией взять из БД структуру без этого id (всё равно мы его уже знаем)

Ну как же не нужен. По id мы определяем с чем работаем.

дык когда вы запросите такую структуру вы её запросите по какому-то id, который УЖЕ известен

невоможно это будет заархитектурить потому что там id а он скорее всего прикладному слою не нужен. Правильный путь может быть таким: по id функцией взять из БД структуру без этого id (всё равно мы его уже знаем)

Да это правильно, в DDD даже иногда делают специальный объект FooId для объекта Foo, чтобы скрыть реализацию id

DDD?

domain driven design

а там уже можно на слое данных быстренько подменить auto increment id на uuid какой-нибудь и вся логика этого даже не заметит

далее момент - а генерит id эта хрень? судя по аннотации

щас бы на стороне клиента генерить idшники 32-64 бита длиной и надеяться что они не пересекутся, ага

64 ещё туда-сюда если правильно заморочиться - заморчивается ли эта фиговина?

Это скорее всего аннотация для правильного построения запроса

UserRecord user = UserRecord.get(id);

Если вызывается вот такое то билдер внутри найдет колонку с аннотацией @Id и добавит ее в часть WHERE и сравнит с пришедшим аргументом

UserRecord user = UserRecord.get(id);

и внутри структура с id - и что будет если эти id окажутся разными потому что база решит так ответить?

Если вызывается вот такое то билдер внутри найдет колонку с аннотацией @Id и добавит ее в часть WHERE и сравнит с пришедшим аргументом

Так это может быть верным же

UserRecord.get(id); вот по такой записи орм не может понять по какой именно колонке нужно выбрать строку. А аннотация ей подскажет.

// Update auto increment columns. auto info = getColumnBindings(getIdColumn); if(info.autoIncrement) { // Fetch the last insert id. query = SelectBuilder.lastInsertId; ResultSet id = executeQueryResult(query); // Update the auto incremented column. info.set(this, id[0][0]); пиздец

UserRecord.get(id); вот по такой записи орм не может понять по какой именно колонке нужно выбрать строку. А аннотация ей подскажет.

Ну даже вот звучит неправильно - БД не таблицы возвращает. В совсем запущеном случае можно сделать SELECT и получить 3 таблицы подряд

в PG, по крайней мере.

так орм сама контролирует чтобы запущенных случаев не было

так орм сама контролирует чтобы запущенных случаев не было

ну я вижу как она классно инкремент делает

Будет в select просто перечисление колонок структуры, в FROM подставится имя из аннотации @table а в WHERE подставится колонка из аннотации @id

ох она наконтролирует

А разве нет таких nosql решений?

SQL тут ведь лишний. Набор простых таблиц + пересечения по ним + ключи.

А то мучаются с SQL зачем-то.

Там есть джоины значит не лишний

а вот в nosql невозможны джоины

джойны можно тоже в виде функций API описать

просто очевидно что им SQL прямо мешает

даже не знаю как приложения БД до сих пор писали

Жаль там нету примеров, особо не понятно как оно все работает

Или вот ещё вопрос: допустим данных станет много и надо будет партиционировать или ещё что-то сделать - лезем руками в БД ведь? И как потом ОРМ будет работать? Придётся его глубоко изучить + глубоко изучть SQL.

орм сама ничего не решает, а только ретранслирует в субд. целостность обеспечивает субд.

ну вот у нас огромный объём данных

тормозить стало всё

и мы впервые лезем туда и охреневаем чего она там наделала

и пытаемся понять как оно работает

такой сценарий?

виновата не орм, а програмеры

работа орм прозрачна. по крайней мере должна такой быть.

виновата не орм, а програмеры

вторая отмазка на все случаи жизни)

ну, что ей напишут, то и сделает

в реале дело выглядит так: неофит прибегает и думает "нафиг SQL если можно ОРМ?" и фигачит

и фигачит

ERROR: S client not available

огребает проблем и думат: "О, это был плохой ОРМ, нужен более лучший", и так несколько итераций

ну, фигачит, заглядывая в кишки БД и посматривая на генерируемые запросы и их параметры.

я вас умоляю

он придёт к выводу что надо точнее тюнить ОРМ

Или вот ещё вопрос: допустим данных станет много и надо будет партиционировать или ещё что-то сделать - лезем руками в БД ведь? И как потом ОРМ будет работать? Придётся его глубоко изучить + глубоко изучть SQL.

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

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

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

Вы уже 2 часа про ORM пишите

Где ты увидел мучения то? написать 2 строчки конфига. Остальной проект вообще никак не трогается.

Вы уже 2 часа про ORM пишите

Как ты собрался переписать unity на D если там небось кода дофига?

Где ты увидел мучения то? написать 2 строчки конфига. Остальной проект вообще никак не трогается.

чтобы их написать надо ЗНАТЬ. выгоднее знать БД чем какой-то ОРМ (который школьник написал и забыл)

Ну ОРМ не отменяет знания БД. Она просто помогает писать меньше бойлерплейта

А знать нужно конечно

Как ты собрался переписать unity на D если там небось кода дофига?

Во-первых, как одно связана с другим, а во-вторых, кто сказал, что я собрался переписать Unity на D?

Во-первых, как одно связана с другим, а во-вторых, кто сказал, что я собрался переписать Unity на D?

Просто помню сообщения от тебя часов 5 назад, а спросить забыл

Просто помню сообщения от тебя часов 5 назад, а спросить забыл

О.о Нефига у тебя кэш-память огромная Я хочу использовать вместо C# D в Unity, переписывать сам Unity я не собирался (в любом случае, пока)

Ну ОРМ не отменяет знания БД. Она просто помогает писать меньше бойлерплейта

ОРМ подразумевает очень глубокие знания БД и ОРМ. А в реальности мы имеем другое - люди воспринимают ОРМ как лёгкий удобнй способ. И авторы ОРМ их так рекламируют.

чтобы их написать надо ЗНАТЬ. выгоднее знать БД чем какой-то ОРМ (который школьник написал и забыл)

Если школьник написал и забыл - это точно неправильная орм)

Если школьник написал и забыл - это точно неправильная орм)

Пока головой не ударишься не поймёшь же

О.о Нефига у тебя кэш-память огромная Я хочу использовать вместо C# D в Unity, переписывать сам Unity я не собирался (в любом случае, пока)

Дык от Юнити ничего не отанется же? Там же фишка в сценариях вроде

и в редакторе

Я не знаю вообще как-то из чего состоит юнити. Если это графический движок то явно он не на шарпе написан, может там биндинги к шарпу?

Я не знаю вообще как-то из чего состоит юнити. Если это графический движок то явно он не на шарпе написан, может там биндинги к шарпу?

Интересный вопрос. Не знаю, если честно

Дык от Юнити ничего не отанется же? Там же фишка в сценариях вроде

API останется

3d это очень сложно, а вот 2d движок я бы поковырял

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

Atrium

Это не движок

А игра

Точнее

"Игра"

Т.к. там почти ничего нет