|
ChA * Именно это я и пытался выяснить. Одного не могу понять, почему смысл вопроса похоже был понятен почти всем, кроме Вас.
Я не понимаю, почему Вы ожидали от меня ответа на вопрос, адресованный не мне. Собственно, я не читал Вашу беседу с Димой, и увидел его только в Вашей же цитате.
Также меня удивляет, что Вы задали вопрос, ответ на который я практически дал еще пару страниц назад, и оказывается просили на него ответить.
ChAИскренне рад за Вас, что живете в идеальном мире
Хм. До сих пор я считал, что сталкиваюсь с кучей недоработок в технологии разработки. Но за последние несколько дней уже в третий раз слышу, что ситуация, которая с моей точки зрения кишит недостатками, с точки зрения MSSQL-разработчиков является недостижимым идеалом. Забавно...
ChAи никогда не сталкивались с тем, что имея API, тем не менее, сплошь и рядом использующие его разрабочики делают ошибки при его использовании, не говоря уж о том, что и разработчики API далеко не безгрешны.
Прежде всего, я прошу Вас не уводить разговор в сторону, и таки объяснить, что за взаимодействие Вы подразумеваете и какое место оно занимает в технологии разработки. Просто нарисовать картину: есть такие-то люди, у них такие-то обязанности, они делают то-то, и если не договорятся вот здесь вот об этом, будет плохо.
Далее, Вы в очередной раз рисуете некую странную картину. Раньше у нас была разделяемая сессия, теперь оказывается в результате "ошибки в использовании API" программист клиента по собственному разумению устанавливает уровень изоляции. Хотелось бы получить более подробное описание ситуации, как Вы ее видите.
Наконец, отмечу, что если мой программист начхает на оговоренный интерфейс и выполнит что-то, в том числе ALTER SESSION, в обход специфицированного взаимодействия - я, видимо, буду шокирован. До сих пор я так был шокирован единственный раз в жизни; отмечу, что те двое сотрудников - единственные до сих пор, кого я уволил. И надеюсь больше с таким не встретиться. Если хотите, считайте это идеальным миром.
ChAНо тем не менее эта же возможность может дать в определенных ситуациях прирост производительности и/или гарантию целостности, если, разумеется, грамотно ею пользоваться, просчитывая последствия.
Не знаю, пожалуй что не готов судить. С одной стороны, "фичи лишними не бывают", всегда можно не пользоваться теми, которые не подходят к ситуации. С другой стороны, я как-то затрудняюсь представить себя, объясняющим, когда и как стоит использовать эту фичу.
В целом, пожалуй, я бы отметил две вещи. Первая: как только мы говорим, что нужно грамотно пользоваться и просчитывать последствия, мы тем самым поднимаем требования к разработчику; об упрощении разработки речи не идет (согласен, вполне может идти об эффективности). Вторая: если вспомнить, что стартовали мы с консистентного чтения, то в целом я весьма рад, что его существование в Oracle избавляет меня от просчета подобных ситуаций. Что касается цены вопроса... в принципе, конечно, консистентность стоит определенных ресурсов, требуя дополнительных чтений. Я замерял производительность запросов в зависимости от количества старых данных, которые нужно поднять, и пришел к выводу, что в практически встречающихся ситуациях соответствующие потери пренебрежимо малы, меньше одного процента; чтобы получить серьезную разницу, надо специально моделировать ситуацию.
ChAЗапуская мою процедуру, программист КЧ в любом случае получит вполне консистентный отчет, даже не задумываясь, а какой же он должен был проставить TIL для этого.
Простите, я снова не понимаю технологии, которую Вы подразумеваете. Программист клиентской части никогда-никогда-никогда не устанавливает TIL, если, конечно, мы говорим о процессе разработки с четко очерченными полномочиями (то есть о процессе, где есть смысл говорить о "программисте КЧ"). Вместо этого программист КЧ вызывает специфицированные для него методы интерфейса; для простоты считайте, что это ХП. Программист серверной части реализует эти методы, в том числе распихивает по ним установку уровня изоляции, если это нужно. Скажем, если Вы будете программистом КЧ, получите от меня задание что-нибудь вроде "сразу после коннекта к БД вызвать ХП Init с такими-то параметрами". Эта процедура сделает много всего, скажем даст сессии полагающиеся роли, настроит row-level security, инициализирует серверные переменные и прочий контекст, в том числе, если нужно, выполнит ALTER SESSION SET ISOLATION_LEVEL. Вы как программист КЧ об этом думать не будете, а знать - только если полюбопытствуете.
ChA * В некотором смысле, мне кажется это более грамотный подход к API, чем меньше разработчику КЧ нужно знать о сервере, TIL и прочей лабуде, тем лучше. IMHO.
Возможно, это более грамотный подход, но я не понял, с какой хренью Вы его сравниваете и откуда Вы ее откопали.
|
