Набрасываю: в СУБД нельзя по человечески провести интеграционное и юнит тестирование, потому держать логику в СУБД ацтой  




Тебя интересует зачем нужны тесты вообще? Или ты считаешь что приведенные тобой примеры чем-то кардинально выделяются?

LSD, я не в состоянии оцнить те недостатки,  о которых ты говоришь, в виду не понимания преимуществ, о которых ты умалчиваешь.

Это сообщение отредактировал(а) Zloxa - 29.7.2011, 14:55

Зачем нужны юнит тесты, часть 1
Зачем нужны юнит тесты, часть 2

LSD, не смотря на то что букав много, я стоически их осилил полностью. Все ждал когда мне откроется сокровенное. 

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

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

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

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

эм... поэтому в группе разработчиков у одно из моих знакомых (по форуму, лично не знаком) юнит-тесты пишет не разработчик модуля.

Да, это выход. И такой подход одинаково применим как к прикадной логике на pl/sql, так и к логике на жаве.

полуоффтоп.

LSD, не можешь подсказать, платформа жавы реализует механизм отслеживания взаимных блокировок? Что-то, на вскидку, не могу припомнить упоминания о таком. Он, имхо, жизненно необходим когда разраб прикладной логики заберет на себя рализацию изоляции транзакций.

И еще. Поможет ли инструментарий юнит тестов, дать заключение о корректности поведения тестирования модуля в конкурентной среде?

Я не говорю, что возможности нет. Я спрашивал как это реализуется, потому как я не слышал про юнит тесты для СУБД.




Ты не правильно понимаешь суть юнит тестирования. Юнит тестирование не отменяет интеграционного и user acceptance testing, а просто дополняет его. Юнит тест тестирует маленький функциональный компонент (например класс) в изолированной среде, на предмет выполнения этим компонентом формального контракта. Смысл юнит тестов, это раннее обнаружение отклонений поведения компонента от контракта. И поэтому юнит тесты обычно запускаются во время сборки проекта.

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





Я вообще не понимаю о чем ты  Приведи пример.

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

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


Самый простой пример взаимной блокировки - когда процесс1, удерживающий блокировку ресурса А пытается захватить ресурс Б, удерживаемый процессом 2, который в то же самое время пытается захватить ресурс А. 

У оракла есть какая-то процедура, позволяющая отслеживать взимные блокирвоки. У МС, емнип - тоже. В случае обнаружения попытки взаимной блокировки, одна из сессий прерывается. Иначе у нас существует громадный риск что приложение встанет колом. Винда, как я помню, не следит за дедлоками. Следит ли жава - не знаю, не слыхал.   Потому - спрашиваю


Это сообщение отредактировал(а) Zloxa - 1.8.2011, 12:37

Потоки JVM не убивает, но дедлоки детектит и можно программно их обнаружить (и прибить, если захочется).

стыдно признаться, но про result_cashe узнал лишь недавно.

На сколько я понял резалт кэш может быть настроен как для pl/sql функции, так и для запроса. Резалткэш функции сбрасывается при коммите в таблицу, указанной в RELIES_ON. Для запроса, пока еще не понял, пока из статей остается ощущение, что резалткэш запросов не сбрасывается а обновляется при коммите в целевую табилцу. Гранулярность резалт кэша - инстанс датабазы, т.е. в отличи от модели кэширования которую я предлагал ранее (с кэшированием в глобальных пакетных переменных и сбросом по алерту), работает не только для одной сессии, а для всех сессий, которые попадают на этот инстанс.

Мне кажется что эта фича аккурат для твоего примера.

Это сообщение отредактировал(а) Zloxa - 4.7.2013, 15:39

При реализации навороченных исчислений на базе данных оракл или другой, лучшим выбором будет реализация с помощью встроенного в базу данных инструмента, такого как pl/sql или java в виде Stored Procedures. На оракл, хранимые процедуры можно писать и на Java. Производительность системы написанной с помощью хранимых процедур будет более высокой за счёт того, что код и данные будут на одной и той-же машине. Мне приходилось работать с системами где было необходимо реализовать вычисление различных коэффициентов и статистики на основе данных в таблицах. Перенос логики в PL/SQL в десятки раз ускорил операции. Когда код начали крутить на онлайновой системе, DBA не могли поверить, что расчёты стали выполнятся мгновенно. Исполнение кода процедур внутри процесса базы данных очень сильно ускоряет расчёты. И не важно на java написана процедура или на PL/SQL. 

Что-же касается ORM, то он хорош для CRUD операций с клиентских машин или веб-серверов. Делать системы сложных расчётов на ORM - это стрелять себе в ногу.

dobrolub, пардон, ко.   

Я в основном говорил про im memory cache, не дисковый. Т.е. поднимаем сотню дешевы серверов которые в памяти держат данные и отдают по запросу.

Это и есть инмемори.  В SGA инстанса.