Spring Framework 2.5

ORM нужен хотя бы для того чтобы уйти от SQL-injection уже на этапе проектирования, а не отлавливать косяки в работающем приложении.

> SQL-injection уже на этапе проектирования
Еще одна выгода :)

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

:)

P.S.
Я не в коей мере не говорю, что ORM панацея. Для функциональных языков это вообще убийство.

>В ходе беседы ни разу не говорил, что валидации перед DB не нужно.

ORM вообще нужен для того чтобы данные из базы представлять в объектном виде. Состояние объектов долдно точно соответсвовать констрейнтам наложеным на базу. Если не соотвествует - это как база данных без констрейнтов. ЗАчем нужны констрейнты расказывать? Или у вас объекты не имеют корнстрайнтов внутри себя и являются таким себе типизированным хешом без намека на необходимость валидного состояния?

>HTTP-запрос? Да.

Компилятором не проверяются да?

>Это только если вы позволяете это делать

Ага. ORM в одной системе автоматически отменяет возможность работы с этой базой другой системе и сисадмина c phpMyAdmin,psql,sqlplus так?

>Если же архитектурно не возможно иметь Application Server через который все работают с данными...

А в каком месте это хорошо? 3-tier архитектура абсолютно не предполагает, что middletier должен быть в виде единственного appserver, который является мордой к RDBMS, иначе это уже никакой не 3-tier. AppServers может быть много, у них могут быть разные задачи, и они могут содержать совершенно различную бизнес логику. Смысл middleware выкинуть локику из клиента (для которой нужно таскать дофига данных + это несекурно), и выкинуть логику из базы( где ее держать неудобно в следствии ограниченых возможностей базы в том числе - не всегда логика ограничена переколбасиванием данных в базе). Общая цель упрощение каждой из систем и реализация конкреных функций (клиент, бизнеслогика, данные) там где это наиболее удобно. Не вижу каким образом превращение связки MW-RDBS в один элемент и запихивание в один сервер абсолютно несвязной логики служит цели упрощения разработки и развития больших сложных приложений.

>То и в этом случае не должно вызывать серьезных проблем. В этом случае только одна серьезная проблема - синхронизация.

О - это очень интересная проблема. ДАже в примере, который вы привели с тасканием бинов по сетке ORM очень активно вставит достаточно немало арматурин в колеса, если все это нельзя сделать в виде координируемой одним менеджером транзакций системе. Вы давно пробовали asyncronous multimaster установки систем с ормами? Например поднять бин в одном маппере пересунуть его по сетке в другую vm и сохранить там? Попробуйте на досуге - поимеете много удовольствия войны с его проксями на коллекции, установленными первичными ключами и удивлениями мапперов по поводу мол "какого хрена бин выглядит как будто мой, а в кеше второго уровня или кеше транзакции он отсутствует? Хазяин ты меня абмануть пытаишься?"

>Почему примитив? Наследие поддержки?

Нет. констрейнт на базу данных. В базе данных написано not null. Или по вашему норомально иметь объектно представлени записи с нулом там где в базе написано его быть не может?

> В этом случае, например Spring при работе с command имеющий int поле и данными "ААААА" для него будем иметь в поле 0 и в errors объекте rejectValue на это поле с описанием причины почему значение для этого поля было отклонено.

Классна. Я просто радуюсь. Задача была показывать формочки с данными, валидировать их и сохранять в базу и показывать в виде листающихся табличек на вебе. И что имеем для реализации данного? Мегафреймворк c коммандами, ORMами, и прочей фигней. И ладно бы он решал эту задачу красиво, элегантно, требовал минимум усилий для реализации и т.д. ТАк нет - имеем большой набор костылей с прилагающимся к ним толстым мануалом, как проверять вещи типа "ожидаемое значение целое число, а в запросе пришло пустое место". Замечательно. Сумма 2х чисел в кластерном варианте. Вам не приходило в голову что phpMyAdmin выполняет ровно ту же задачу при чем на любой базе без всей это херни, при чем на любой базе?

Я теперь понимаю к джаве такое отношение с такими ынтырпрайз решениями простых задач.

>При наличии записи в errors обработка запроса дальше формы ввода не пройдет и в БД не попадет.

Command не является объектом ORM. Догадайтесь почему.

>Вот, кстати, и преимущество ORM - наличие единых правил для валидации.

Вопрос был поставлен почему нельзя валидировать данных в объекте ORM. Все примеры что вы приводите валидируют данные до ORM.

>Вы данные в любом случае храните в памяти.

С какой радости? В базе.

>Здесь большей проблемой может выступать overhead за счет создания новых объектов и вызов SET методов.

А так же необходимость реализации логики манипуляции этими обектами. Что такое JSP? Это такой XSL для обектов.

>Но это решается за счет использования пула объектов, в частности.

Зачем это вообще надо?! Вы послушайте себя вы предлогаете решение которое сопровождается многжеством проблем и костылей. Я пока не услышал ни одного аргумента обясняющего зачем оно вообще нужно для вышеизложенной задачи?

>Вы увидите, что расход памяти не сильно возрастет (если, конечно, не плодить мильены и не отдовать их GC).

Плодит их ORM. Я тут непричем.

>ORM нужен хотя бы для того чтобы уйти от SQL-injection уже на этапе проектирования, а не отлавливать косяки в работающем приложении.

Чтобьы уйти от SQL injection надо освоить PreparedStatement.

>Против - только увеличение памяти (ой ли?) и анакуя?

Против - посмотрите в собственный код. А потом посмотрите в конфигурацию маппера. НАйдете там (или ав аннотациях) xmlину в которой описано чего из базы данных куда должно быть положено в объекте. А дальше найдете в своих JSPшках такой себе XSL который ходит по объектам.

Внимание вопрос, дорогие знатоки: Почему XML описывающий мапинг базы данных на обекты не может описать маппинг данных на формы имеющее представление в вебе? Решите задачу зачем вы переганяете с помощью маппинга таблицы в объектное дерево, чтобы трансформировать это дерево посредством JSP в таблички на вебе?

>А вот тут мы вспомним про JTA, засунем commons-transactions/file

Спасибо огромное, я как раз искал как имплементироватл транзакции с участием файлов. Почти пошёл изобретать велосипед :) Все таки стоит иногда флеймы читать!

>Смотрю. Как это мне поможет нормально подключить например mx4j или любую другую 3rd party либу которая не аннотирована соответствующим образом и не наследуется от спринговых классов? Никак? Спринг хороший фремфорк, но он глобальный: претендует нак то, чтобы все написать спринг вей

Неправда. Никто не заставляет тебя использовать аннотации в твоей системе. Все 3rd парти компоненты включаются через config.xml со спринговой конфигурацией. Прелесть спринга в том, что ни одна из используемых компонент НЕ ТРЕБУЕТ спринга. Только, возможно, main() или какая-то спринг обёртка для всей системы должна знать как связать все компоненты вместе используя спринг.

>Чтобьы уйти от SQL injection надо освоить PreparedStatement.

Как мне ее засунуть в ту-же джангу?

> поле a может принимать значение 1 или 2 в случае если поле b положительное, и 3 или 4 если отрицательное

Автора утопить в сортире за ненормализованную базу данных. Граблей в ней он с большой вероятностью огребет независимо от наличия/отсутствия ORM - просто в силу недостаточного радиуса кривизны своих передних конечностей.

> Состояние объектов долдно точно соответсвовать констрейнтам наложеным на базу.
Абсолютно не обязано.

> Если не соотвествует - это как база данных без констрейнтов.
А констрейнты здесь причем?

> Или у вас объекты не имеют корнстрайнтов внутри себя и являются таким себе типизированным хешом без намека на необходимость валидного состояния?
Ну а это-то при чем?

> Ага. ORM в одной системе автоматически отменяет возможность работы с этой базой другой системе и сисадмина c phpMyAdmin,psql,sqlplus так?
Нет. Не так. В ваших руках позволить изменять данные извне или нет.


> А в каком месте это хорошо?
Это ни хорошо ни плохо. Это зависит от задачи. А обсуждение этого сильно уведет от темы обсуждения.

> О - это очень интересная проблема. ДАже в примере, который вы привели с тасканием бинов по сетке ORM очень активно вставит достаточно немало арматурин в колеса
Ну какие арматируны? Где? Еще и активно. Приведите примеры. А то все обсуждение одни домыслы.


> если все это нельзя сделать в виде координируемой одним менеджером транзакций системе.
Можно. Но не всегда оправдано. Зачем складывать все яйца в одну корзину? Потом есть такая вещь как интеграция.


> Вы давно пробовали asyncronous multimaster установки систем с ормами?
Не только пробовал, но и пишу в данный момент времени.
Кроме того, все это крутится на "несбалансированном" кластере.


> Например поднять бин в одном маппере пересунуть его по сетке в другую vm и сохранить там?
Как два пальца обо сфальт :)


> Попробуйте на досуге ..., а в кеше второго уровня или кеше транзакции он отсутствует?
Успешно пробую, при чем за это получаю деньги.
А на досуге я отдыхаю.

А чтобы не было глупых вопросов про кэш второго уровня его можно реализовать самому, если нужно, конечно. В чем проблема?


>>Почему примитив? Наследие поддержки?
>Нет. констрейнт на базу данных. В базе данных написано not null. Или по вашему норомально иметь объектно представлени записи с нулом там где в базе написано его быть не может?

Да! Это нормально иметь в представлении записи с null там, где в базе написано, что его быть не может!
Есть объект User, у него есть поле id - в базе на него not null.
Но! При создании _нового_ пользователя ему еще идентификатор не присвоен, хотя этот объект мы должны гонять в браузер и обратно пока пользователь не введет все регистрационные данные.
И только когда объект уйдет в БД, в этом объекте вместо id = null появится реальное значение и дальше код будет работать с тем же объектом который реально уже имеет идентификатор в БД.


> Задача была показывать формочки с данными, валидировать их и сохранять в базу и показывать в виде листающихся табличек на вебе.
Такой задачи не было. Ни в одном предыдущем посту.
> ... ТАк нет - имеем большой набор костылей ...
> ... Вам не приходило в голову что phpMyAdmin выполняет ровно ту же задачу при чем на любой базе без всей это херни, при чем на любой базе?

Класно. 5+! :)
Сам придумал задачу, упростил до невозможности и решил ее (phpMyAdmin). После чего говорит что те мегакостыли нахрен не здались.
И знаешь что? Я с тобой соглашусь. Чтобы сделать быдлоподделку для редактирования табличек в которой каждый месяц находят по security bug не нужны Java, J2EE и прочий отстой.

> А так же необходимость реализации логики манипуляции этими обектами. Что такое JSP? Это такой XSL для обектов.
В любом случае придется чем-то манипулировать.

> Плодит их ORM. Я тут непричем.
И без ORM их много. Или вы за то, чтобы отдавать ResultSet сразу на JSP? Тогда зачем вообще Application Server?
Не проще поднять WEB Server внутри Oracle? К тому же у Oracle есть такое решение.

>Как мне ее засунуть в ту-же джангу?

Засунь Джангу туда же :)

>Как мне ее засунуть в ту-же джангу?

http://www.python.org/dev/peps/pep-0249/

Cursor Objects
.execute(operation[,parameters]) 
          
            Prepare and execute a database operation (query or
            command).  Parameters may be provided as sequence or
            mapping and will be bound to variables in the operation.
            Variables are specified in a database-specific notation
            (see the module's paramstyle attribute for details). [5]
            
            A reference to the operation will be retained by the
            cursor.  If the same operation object is passed in again,
            then the cursor can optimize its behavior.  This is most
            effective for algorithms where the same operation is used,
            but different parameters are bound to it (many times).

>Внимание вопрос, дорогие знатоки: Почему XML описывающий мапинг базы данных на обекты не может описать маппинг данных на формы имеющее представление в вебе?

а бизнес-логику тоже в ХМЛ описывать? я бы лично не против если бы это было легко и просто

а еще поделитесь каким образом ХМЛ будет исполняться даже в случае который предлагаете Вы? У ХМЛ появился чистый (не объектный) рантайм? ХСЛ? а ХСЛ на чем имплементирован? не на объектах? хуже того - не на В3Ц ДОМ ?

>Решите задачу зачем вы переганяете с помощью маппинга таблицы в объектное дерево, чтобы трансформировать это дерево посредством JSP в таблички на вебе?

Может быть именно для того чтобы все сущности системы были выражены в терминах обьектной модели? Вы имеете что-то против объектной парадигмы? Что конкретно против?

>Ага. ORM в одной системе автоматически отменяет возможность работы с этой базой другой системе и сисадмина c phpMyAdmin,psql,sqlplus так?

Не так.

Вообще столько "умных" слов я давно видел. Как выглядит ORM в той же Django, вот типичный запрос:

Article.objects.filter(date__month=11, date__year=2007) Reply.objects.filter(article__author__username='vasya-pupkin', date__gte=date.today()-timedelta(1))

Взять все статьи за ноябрь 2007 года, и выдать все коментарии Васи Пупкина к этим статьям за время не позднее чем вчера. Ничто не мешает задать прямой SQL-запрос. Мне по этому коду не видно никакого перерасхода памяти и т.д.

>Автора утопить в сортире за ненормализованную базу данных. Граблей в ней он с большой вероятностью огребет независимо от наличия/отсутствия ORM - просто в силу недостаточного радиуса кривизны своих передних конечностей.

Нормализуй:

CREATE TABLE x (a int NOT NULL, b int NOT NULL, CHECK( ( ( a=1 OR a=2 ) AND b>0 ) OR ( ( a=3 OR a=4 ) AND b<=0 )));

>Засунь Джангу туда же :)

Пришел dimag и все опошлил.

> Article.objects.filter(date__month=11, date__year=2007) Reply.objects.filter(article__author__username='vasya-pupkin', date__gte=date.today()-timedelta(1))

> Мне по этому коду не видно никакого перерасхода памяти и т.д.

Мне тоже. За этим кодом может находиться что угодно. И сколько это "что угодно" ест памяти и как работает в нутри по приведенному выше коду не видно.

Кроме потребления памяти есть еще один параметр - производительность.
Кроме производительности есть еще один - нагрузка на БД.

По приведенному выше коду опять не ясно, что с этими вещами.
В общем получаем меньше кода, но ХЗ как оно себя поведет.

> Нормализуй: > CREATE TABLE x (a int NOT NULL, b int NOT NULL, CHECK( ( ( a=1 OR a=2 ) AND b>0 ) OR ( ( a=3 OR a=4 ) AND b<=0 )));

CREATE TABLE x (id long NOT NULL);

CREATE TABLE pos_x (main_id long NOT NULL, a int NOT NULL, b int NOT NULL, CHECK(a in (1,2), CHECK(b>0 ));

CREATE TABLE neg_x (main_id long NOT NULL, a int NOT NULL, b int NOT NULL, CHECK(a in (3,4), CHECK(b<=0));

И?

>В общем получаем меньше кода, но ХЗ как оно себя поведет.

Ведет оно себя до неприличия корректно, и кушать не просит.

>Да! Это нормально иметь в представлении записи с null там, где в базе написано, что его быть не может!Есть объект User, у него есть поле id - в базе на него not null.Но! При создании _нового_ пользователя ему еще идентификатор не присвоен,

совершенно верно, например в конструкторе и даже сразу после него. или ИД объекта должен быть известен еще до вызова конструктора? а откуда его взять? для того чтобы сгенерировать ИД нужно в базе создать запись - стало быть все данные о сушности уже известны. объект как раз и есть способ передать эти данные в базу одним вызовом.


>хотя этот объект мы должны гонять в браузер и обратно пока пользователь не введет все регистрационные данные. И только когда объект уйдет в БД, в этом объекте вместо id = null появится реальное значение и дальше код будет работать с тем же объектом который реально уже имеет идентификатор в БД.

а вот тут я бы не согласился. пихать замапленные на базу объекты в уровень представления (view level в MVC) - плохая практика. как минимум по двум причинам

1) lazy loading after session closing ( тоесть ексепшин. либо не использовать лези лоадинг, что тоже не всегда оправдано и уж точно не изза этого юз-кейса оправдано может быть )

2) backside effects caused by model transformation (например нужно укоротить какой нибудь длинный текст при отображении но не в базе, если делать это прямо в объекте замапленном на базу непосредственно перед передачей во вью, что прямо таки напрашивается, то при закрытии и флаше сессии сами догадайтесь что будет ...)
если

> Ведет оно себя до неприличия корректно, и кушать не просит.
Про Java (web applications) тоже самое. Только функционально на голову выше.

> Только функционально на голову выше.

Чем конкретно явовские орм на голову выше SQLAlchemy?

>Абсолютно не обязано.

Обязано. Иначе это не ORM. Одна из задач ORM - абстракция от базы данных и SQL. Если у тебя разные констрейнты на базу и на объекты - ты будешь выгребать SQLException из базы на тему constraint violation один за другим.

>А констрейнты здесь причем?

При том что если в базе написано:

...a int not null,...

Это значит что в обекте должно быть

private int a=1;

void setA(int a) { assert a!=0; this.a = a; }

Или ССЗБ.

>Ну а это-то при чем?

При том. Что обект может иметь некие констрейнты. Например вышеописанный. В запросе придет "a=". Общем случае движок попытается сконвертить null в int как 0, и потом вызовет код валидации. Только в этот момент он отгребет AssertionError и упадет. Это если есть эти констрейнты. Если нет - тогда при попытке сохранить в базу x.setA(0); store(x) вылетить SQLException. Только вылетит вообще где попало, а подороге из-за этого 0ля перехерится может еще дохрена всего. Что еще неясно?

>Нет. Не так. В ваших руках позволить изменять данные извне или нет.

Именно. А поскольку доступ к базе есть имеем что? Правильно. Для других систем - X/Open DTA через единого координатора, и строгий запрет сисадмину лазить туда руками - то есть дополнительные ограничения (при чем очень дорогие). Клаасно! Любой чих на тему простенького интерфейса "для чигонибудь" будет требовать реализации системы в архитектуре с координатором распределенных транзакций и интеграции этой бойды в единую мегасистему. Потому что кто-то умный заюзал технологии Enterprise уровня для реализации бровзера базы данных.

>Это ни хорошо ни плохо. Это зависит от задачи.

ЗАдача была озвучена - листать и менять базу данных.

>у какие арматируны? Где? Еще и активно. Приведите примеры. А то все обсуждение одни домыслы.

На счет этого небеспокойтесь по этим граблям я хорошо походил. Давно пробовали объект поднятый в том же обжектбридже или гибернейте с лейзи связями пересовывать по сетеке в другую эквивалентную систему и сохранять его там? Вот попробуйте. Да просто попробуйте сериализовать такой объект, и востановить в другой сессии и сохранить.

>Можно. Но не всегда оправдано. Зачем складывать все яйца в одну корзину? Потом есть такая вещь как интеграция.

Тут мы остановимся. Очевидно вы не поняли вопроса. 2 системы. В одной бин поднят в маппере. Проблема: передать его по протоколу который unaware про ORM (сераилизация - такой протокол), потому что в бине есть LazyProxy маппера которые с одной стороны могут не быть сериализуемыми, с другой стороны даже если они сериализуемы - они могут не быть востанавливаемы в другом маппере, по причине незнания оного об этом объекте. Это все не теория - "это жизнь" в которой я достаточно походил по подобным граблям.

>Не только пробовал, но и пишу в данный момент времени. >Кроме того, все это крутится на "несбалансированном" кластере.

Кластер и асинхронный мультимастер - это 2 большие разницы.

Все что я говорю - это не неразрешимые проблемы. В конце концов мы это все порешали. А потому глядя на такое количество костылей и системы был похерен не только ORM, но и RDBMS. И теперь все дешево, быстро, с минимумом кода, просто и в 60 метров помещается на серваке вместе с томкетом.

>Как два пальца обо сфальт :)

Серьезно? Вы или этого не делали или у вас действительно ORM без связей и констрейнтов и т.д. Один обект у него поле, коллекция, ленивая. Нука объясните как он его сериализирует и просунет в другую vm?

Что за ORM? Hibernate?

>А чтобы не было глупых вопросов про кэш второго уровня его можно реализовать самому, если нужно, конечно. В чем проблема?

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

>Да! Это нормально иметь в представлении записи с null там, где в базе написано, что его быть не может!

Вопросов больше нет. Тогда понятно что вам и констрейнты ни к чему и слово инвариант ничего не значит.

>Есть объект User, у него есть поле id - в базе на него not null.

Туторал по primary key к любому ORM хорошо выучили - хвалю. РАсскажите как вы будете ганять туда и обратно этот объек, если он уже поднят (а не создан без связей и ORM про него не в курсе), уже находится в транзакционном кеше и подобные хинты происходят с его полями-ссылками(коллекциями), инстансы которых лежат в этом же кеше, и любая манипуляция с collection reference тут же отражается в ORM для будущего commit. А тразакция в сессии да?

>Такой задачи не было. Ни в одном предыдущем посту.

http://www.linux.org.ru/jump-message.jsp?msgid=2294776&cid=2297299

>Чтобы сделать быдлоподделку для редактирования табличек в которой каждый месяц находят по security bug не нужны Java, J2EE и прочий отстой.

О чем я и сказал в указанном посте. А ты взялся доказывать что данные контролируются компилятором (никому больше такого не говори), привязал валидацию к объектам орма - хотя демонстрировал только команду спринга, и почему-то решил что в табличном виде в базе данные зависят от представления:

http://www.linux.org.ru/jump-message.jsp?msgid=2294776&cid=2297349

Никому больше такого не говори.

>В любом случае придется чем-то манипулировать.

Только в приведенном пример отсутсвует лишнее звено и связанные с этим грабли.

>Тогда зачем вообще Application Server?

5 балов! А orm применяется для того чтобы оправдать существование AS? ДАю справку в данном примере он нафиг не нужен.

>Не проще поднять WEB Server внутри Oracle? К тому же у Oracle есть такое решение.

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

> Чем конкретно явовские орм на голову выше SQLAlchemy?
SQLAlchemy не знаю, не пробовал.
На вскидку:
- 2 phase commit
- lazy loading
- Clustering support
- Clustering cache
- Возможность работы в качестве сервера
- consistency checks
- Поддержка native SQL
- Поддержка встроенных в БД процедур
- Multi object mapping (создание иерархии объектов одним вызовом)
- Object Pool support
- Reusable Object support (когда реально используется один instance объекта для обработки списка результата выборки - экономия памяти)
- Нет привязки к названиям полей в БД и Java code

>а бизнес-логику тоже в ХМЛ описывать?

А где вы увидели бизнес логику в морде к базе данных?

>Может быть именно для того чтобы все сущности системы были выражены в терминах обьектной модели?

Зачем? Какую это принесет практическую пользу?

> Вы имеете что-то против объектной парадигмы?

Где тут объектная парадигма? ПОкажите мне в случае ORM message passing, local retention and protection, hiding of state-process (C) Alan Key.

Я тут ничего кроме дерева отражающего базу данных не вижу.

>Мне по этому коду не видно никакого перерасхода памяти и т.д.

Дело не в этом. Этот код в случае базы морды к базе данных - не нужен. Надо просто объяснить умному движку что вот база данных, а данные надо листать от такие колонки, от по столько на странице. Диалоги редактирования строятся из описалова структуры данных. Можно указать кастомизацию. Все это - практически конфиг. Все остальное человек писать _не должен_.

> При том что если в базе написано:
> ...a int not null,...
> Это значит что в обекте должно быть
> private int a=1;

В общем случае да. Но не обязанно. Примеры? Писал выше.

> движок попытается сконвертить null в int как 0
Уже говорили. Используйте Integer вместо int.

> потому что в бине есть LazyProxy маппера которые с одной стороны могут не быть сериализуемыми
ССЗБ. Не фиг LazyProxy использовать для объектов, которые должны проходить сериализацию.

> Это все не теория - "это жизнь" в которой я достаточно походил по подобным граблям.
Чтобы по подобным граблям не ходить нужно больше теории читать.

> Кластер и асинхронный мультимастер - это 2 большие разницы.
Спасибо, что напомнили.

> ...Нука объясните как он его сериализирует и просунет в другую vm?
ССЗБ. lazy - механизм оптимизации, работающий в рамках одной VM (local).

> Что за ORM? Hibernate?
Собственный. Основан на iBATIS SQLMap.

> Проблема в том что мы уже для реализации бровзилки базы данных
Для бровзилки базы данных не нужно перекидывать объекты в другую VM. Не передергивайте.

> Вопросов больше нет. Тогда понятно что вам и констрейнты ни к чему и слово инвариант ничего не значит.
Прочитайте еще раз. Для какого случая это было написано.

> уже находится в транзакционном кеше и подобные хинты происходят с его полями-ссылками(коллекциями)
Какие хинты? Если уже установленному ID попытаются присвоить NULL значение? Получил отлуп и пинок по яйцам.

> А ты взялся доказывать что данные контролируются компилятором (никому больше такого не говори)
Почитай еще раз, что именно я отношу к данным и какую часть из приведенного списка возможно проконтролировать компилятором.


> Поздравляю - мы таки пришли к этому решению.
И вас с тем же! Желаю и дальше успехов в написании веб мордочек к потабличному просмотру данных из БД.

> Можно указать кастомизацию. Все это - практически конфиг.
Верно.

> Все остальное человек писать _не должен_.
А вас заставляли? Хотите поговорить об этом?

>И?

Что ты тут нормализовал? Оно и так находилось в 5NF+DKNF. Уж не говоря что такой уровень номрмализации и нафиг не нужен на практике.

> Что ты тут нормализовал?

То, что ты просил.

> Оно и так находилось в 5NF+DKNF

Да что ты? А зависимости от неключевых атрибутов тебе нигде не трут?

> Уж не говоря что такой уровень номрмализации и нафиг не нужен на практике.

Точно. Лучше валить на каждый случай наступания себе на яйца изобретать отдельный хитрый констрейнт.

>объект как раз и есть способ передать эти данные в базу одним вызовом.

А до появления ORM эта проблема была неразрешима да?

>а вот тут я бы не согласился.

О чем я и говорю. А ни господа вон формочки из веба прямо в объекты орма пихать собрались.

>В общем случае да. Но не обязанно. Примеры? Писал выше.

Любой где есть хоть какой-то констрейнт.

>Уже говорили. Используйте Integer вместо int.

Нелья. Противоречит констрейнту базы данных. В коде нельзя туда вставлять нул. Он там не может существовать согласно бизнес логике. А она вводом формочек не ограничивается.

>ССЗБ. Не фиг LazyProxy использовать для объектов, которые должны проходить сериализацию.

У меня все обекты должны ее проходить. Дальше что? Без Lazy Proxy ORM вообще практически никогда не нужен. По причине того что на каждый чих будет поднимать пол базы.

>Чтобы по подобным граблям не ходить нужно больше теории читать.

В какой теоретической книжке описано как в случае LazyCollection закрыть транзакцию в контроллере и отобразить ее во view? Что послушаем описание очередного костыля на тему ревиндинг фаз страницы и вставки кода закрытия транзакции в точку где кончает рисоваться отображение?

>ССЗБ. lazy - механизм оптимизации, работающий в рамках одной VM (local).

Это 5 балов! ДУмаешь я этого не знаю? Есть обект A у него есть ленивая коллекция с сотней чайлдов. Объект А реплицируется в другую VM. Проблемы: 1) LAzyProxy - не реплицируется поскольку связан с текущей транзакцией. 2) его отключение приводит к тормозам и океаническому потребление помяти посколько маппер поднимает с каждый экзеспялром A все связи в количестве 100 штук каждого когда они нафиг не нужны 3) отключени прокси приводит к таскани в другой VM связей которые таскать нафиг не нужно. Ы? Что будем писать спецмаппер?

>Собственный. Основан на iBATIS SQLMap.

Ага! А чем же самые кошерные гибернейты с обжектбриджами не подошли что пришлось брать iBatis в котором надо с скэлями ковырятся? Они ж такие клевые беспроблемные мапперы. А реально взяли низкоуровневую штуку большой напильник и пилить велосипед? Ты ж 3 страницы распинался как там все клево что невопрос в ORMах.

>Прочитайте еще раз. Для какого случая это было написано.

Вот и нефиг приводить случай из туториала про первичные ключи - проблему которую я показываю это нецепляет никаким боком. Первичный ключ и его генерация ормом это частной решение частной проблемы и к указанному случаю отношения не имеет.

>Какие хинты? Если уже установленному ID попытаются присвоить NULL значение? Получил отлуп и пинок по яйцам.

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

>И вас с тем же! Желаю и дальше успехов в написании веб мордочек к потабличному просмотру данных из БД.

Я таким не занимаюсь - не извольте беспокоится.

>А вас заставляли? Хотите поговорить об этом?

Все - прошел энтузиазм адвокатить ормы в жспшках?

> А зависимости от неключевых атрибутов тебе нигде не трут?

primary key (b) - так лучше?

> primary key (b) - так лучше?

И где ты это увидел?

>И где ты это увидел?

Добавил.

>А где вы увидели бизнес логику в морде к базе данных?

если говорить о "морде к базе данных" (что уже не факт) то бизнес-логику я вижу в морде к базе данных (представьте себе!) - даже морда к базе данных _может_ (и даже должна) иметь бизнес-логику.

>Зачем? Какую это принесет практическую пользу?

а зачем вообще существуют обьектные модели? какую практическую пользу они приносят? я так думаю - для структуризации проблематики.... Вы не согласны? что можете предложить взамен? спагетти-код? списки? а как же валидация и констрейнты? обойтись можно без всего (в том числе и без программного обеспечения и компьютеров как таковых вообще) - но нужно ли? какую практическую пользу принесет такое самолишение? концептуальная чистота? а какую _практическую_ пользу может принести таковая чистота?

>Я тут ничего кроме дерева отражающего базу данных не вижу.

а этого мало? что еще нужно? а по поводу Алана Кея - так что же Вам мешает? дерзайте!!

> а зачем вообще существуют обьектные модели?

Так исторически сложилось.

>А до появления ORM эта проблема была неразрешима да?

Разрешима но достаточно криво и не надежно. Если уж ударяться в нигилизм то - какие _неразрешимые_ проблемы решили информационные технологии? Почта вроде бы была и до появления интернета. Квантовую физику, теорию относительности и атомную бомбу тоже задолго до того как разработали. Аналогично - в космос полетели тоже без компьютеров (насколько мне известно конечно) Что принципиально нового произошло за последние 50 лет?

>О чем я и говорю. А ни господа вон формочки из веба прямо в объекты орма пихать собрались.

Ну так всему свое место и время. ОРМ не должен выходить за рамки ДАО. Иначе будет горе. А вот в ДАО ему (ОРМу) самое место. Причем именно по соображениям абстракции и всего с этим связанного. Например как прикажете имплементить персистенцию полиморфных иерархий? Никак? Хардкодить? Еще как?

>даже морда к базе данных _может_ (и даже должна) иметь бизнес-логику.

Пример.

>Вы не согласны?

Нет. Для борьбы со сложностью. По моему это Гамма сказал, что никогда в жизни связывани объектных моделей с реальным миром не приносило ему никакой пользы.

>а как же валидация и констрейнты?

Ничего объектного в валидации и констрейнтах нет.

>а этого мало?

Этого черезчур много. Это ненужно.

> а по поводу Алана Кея - так что же Вам мешает? дерзайте!!

Нет в условии задачи. Для вас открытие что ООП - а) не подходит для всех возможных нужд, b) не решает любые задач лучше всего, c) для этого и не предназначено?

В данной задаче объектные принципы ничего не дают.

>Что принципиально нового произошло за последние 50 лет?

И я про то. Просто существует проблема модных технологий которые пихают куда попало, пос ле этого начинают боротся с пролемами возникающими в этих технологиях и изобретая решения этих проблемкоторые существуют только в этих технологиях. Например практически все уверены, что если надо зранить каки-то данные для этого надо RDBMS. Вопрос подходит ли оно сюда мало кто задаст - это ж круто поставим оракл, application server, тапихаем туда ORMов и прочей бойды, и начнем со всем этим вовать изобретая простенький вебсайт. Зачем?

>Причем именно по соображениям абстракции и всего с этим связанного.

И я про то же. А если задача отображать данные из табличек в других табличках, за последние 50 лет способ не изменился. Проще ничего не изобрели. Многие бенефиты весьма сомнительную ценность имеют в конкретных проектах. Типа абстракции от базы данных, возможности кластеризации и т.п. На практике часто ценность проекта такова что подобные перспективы ему никогда не светят.

Ну таки чё, тестить кто будет или так поумничали и разбежались?

>Вопрос подходит ли оно сюда мало кто задаст - это ж круто поставим оракл, application server, тапихаем туда ORMов и прочей бойды, и начнем со всем этим вовать изобретая простенький вебсайт. Зачем?

Ну зачем так, поставим sqlite и будем из админки формачки создавать, для того-же простенького вебсайта на десяток тысяч посещений в сутки.

> Без Lazy Proxy ORM вообще практически никогда не нужен. По причине того что на каждый чих будет поднимать пол базы.
:) ой. А у мну почему-то не поднимает пол базы. И все быстро и без lazy loading?
Может просто изначально проектировать нормально?

> A все связи в количестве 100 штук каждого когда они нафиг не нужны
Проектируй системы, вызовы, кэш с учетом отсутствия lazy.

> Что будем писать спецмаппер?
Зачем? Уже все написано. Только пользовать нужно по назначению.

> Ага! А чем же самые кошерные гибернейты с обжектбриджами не подошли что пришлось брать iBatis в котором надо с скэлями ковырятся?
Потому-что стояла четкая задача куторую кошерные гибернейты и EJB2.0/3.0 не покрывали.
А с SQL в iBATIS не нужно ковыряться. С ними можно работать.

> Они ж такие клевые беспроблемные мапперы.
Да. Для своего круга задач.
В моем случае (текущий проект) Hibernate не подходит по причине больших объемов данных которые ежеминутно изменяются. Каждую минуту происходит пересчет больше 10 млн. записей. Это только для одной сущности. Всего более 50 разных сущностей.
В случае Hibernate либо все данные попадут в память сервера приложений, либо будет несчадно томозить. Его механизмов оптимизации в нашем случае недостаточно.
Использование iBATIS, EJB3, Spring, OSCache позволило разруливать 300Gb базой с постоянным пересчетом данных и при этом JVM съедает не более 2Gb при 300 одновременных коннектов. Среднее время отклика на самый сложный запрос составляет 100мс.


> А реально взяли низкоуровневую штуку большой напильник и пилить велосипед?
Велосипед? Отнюдь. Просто связал воедино те инструменты, которые дали в проекте наибольшую производительность при минимальных усилиях.

> Ты ж 3 страницы распинался как там все клево что невопрос в ORMах.
Каким боком iBATIS не ORM? iBATIS делает mapping из ResultSet в POJO? Делает? Умеет делать lazy? Умеет. Имеет Data Access Object и trandaction Manager? Имеет.
Просто он заточен под другую работу с ДБ в отличии, например, от hibernate. Это не делает его хуже. Это делает его просто другим.

Ужос в какие дебри залезли :), тут 99% ораторов wait() notify() правильно не напишут и не знает как аналогичная штука называется в посикс.

А уж почему так не надо писать синглтон и подавно не знают.
class A {
    private static B instance = null;
    public static B getInstance() {
    if(instance == null) {
        sync...(A.class) {
            if(instance == null) {
                instance = new B(bla bla bla);
            }
        }
    }
    return instance;
}

> А уж почему так не надо писать синглтон и подавно не знают.

Осваиваешь букварь? 8) В следующей главе написано, почему Singleton считается антипаттерном ;)

Большая часть перечисленного в SQLAlchemy есть:
- 2 phase commit
- lazy loading
- Поддержка native SQL
- Поддержка встроенных в БД процедур
- Нет привязки к названиям полей в БД и Python code

То что точно есть. Из того что нет многое вздор, например - "возможность работы в качестве сервера": что это? зачем? Это с одной стороны.

С другой стороны тут интересуются ORMом под яву с возможностями SQLAlchemy: http://www.elharo.com/blog/software-development/2007/06/28/sqlalchemy-for-java. Что само за себя говорит о многом.

И на глазах у изумленной публики Ваше "на голову выше" рушится как хрупкий карточный домик.

> В каком месте? Валидируется запрос. Содержимое запроса может нарушать инвариант бина - валидировать в бине нельзя. Простой пример - в бине int в запросе пусто. Все фреймворки валидирующие запрос после присваивания лажаются тут - в бине null превращается в 0, что в общем случае неверно.

Неверно. Hibernate в этом случае кинет исключение (типа: "пытаюсь присвоить NULL примитиву!!!"). Если NULL-значения возможны - нужно использовать nullable-типы (т.е. обертки Integer/Long/...).

ORM банально удобен тем, что добавляет типизацию в приложение. Я могу передавать в методы объект типа Set<SystemUser>, а не List<ResultRow>.

>>Spring в отношении buzzword'ов - это феномен, так как именно Spring единолично _запустил_ buzzword IoC года так три-четыре назад. >Щас. Это из разряда "Microsoft изобрел internet".

Тем не менее, про Spring - это правда. Он не ИЗОБРЕЛ IoC, он его за-buzzword'ил. А термин "dependency injection", кстати, даже и изобрел.

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

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

> Например практически все уверены, что если надо зранить каки-то данные для этого надо RDBMS. Вопрос подходит ли оно сюда мало кто задаст - это ж круто поставим оракл, application server, тапихаем туда ORMов и прочей бойды, и начнем со всем этим вовать изобретая простенький вебсайт. Зачем?

для абстракции )) для нее, родимой... Кодд зачем вообще придумал РДБМС? аппликейшин серверы - по тем же примерно соображениям (пихают). оверкилл конечно, но не факт что без него будет лучше намного. по крайней мере для простенького веб-сайта. кастомные хенд оптимайзед реализации они знаетели не быстро делаются. и так далее