Здравствуйте, adontz, Вы писали:
A>Вызываешь
A>BeginTransaction()
A>User user = CreateUser(...)
A>CreateSite(user)
A>CommitTransaction()
Непонятно, где я это вызываю. С клиента?

Здравствуйте, adontz, Вы писали:
A>Зачем же ущемлять права эксгибиционистов?
Затем, что эти бывшие гибиционисты ущемляют права других на получение осмысленной информации

Здравствуйте, Sinclair, Вы писали:

C>>Нет, стандартный прием для версирования: "UPDATE ... SET ... WHERE id=? AND version=?". Если этот оператор вернет 0 (ни одного ряда не обновлено) — то значит у нас оптимистическая ошибка. Можно это сделать и batch'ем для нескольких обновлений.
S>Эта реализация оптимистической блокировки примерно соответствует уровню read committed. К сожалению, если требуется хотя бы repeatable read, стоимость оптимизма становится значительно выше и такой наивный подход работать не будет.
Мне REPEATABLE READ ни разу еще не понадобился. Хватает либо READ COMMITED или сразу же SERIALIZABLE. Тем более, что REPEATABLE READ многие базы поддерживают очень плохо (или вообще не поддерживают, как PostgreSQL).

C>>Обычно для сервисов нужно минимизировать длину. Кроме того, тут у нас затраты на память будут на стороне клиента, а не сервера. Так что если он решит похулиганить — то ССЗБ.
S>Да ну? Не может такого быть. Затраты будут ровно на стороне сервера, т.к. ему нужно накапливать изменения, пока с клиента не придет коммит. Клиент может позволить себе забыть о произведенных действиях сразу после того, как он обратился к серверу.
На сервере нам достаточно накапливать только обновляемые объекты. Так что это ничем не отличается от ситуации, когда клиент пошлет на сервер в виде SQL-скрипта пару сотен тысяч команд insert/update.

S>>>Вообще, курсоры в T-SQL, к примеру, так плохи не потому, что вообще плохи, а потому, что код курсора чудовищно медленно интерпретируется.
S>>>Если бы код компилировался в нативную программу, то особой разницы в стейтменте с UDF и курсоре не было бы.
C>>Ну это возможно, во всяких там DB2 и прочих — там процедуры компилируются в С, а потом и в машинный код.
S>Интересно бы глянуть на их данные по производительности.
Очень быстрая, что неудивительно. Хотя сама DB2 — слишком уж монструозная вещь.

S>>>Хочется чего-то более простого; причем очевидный способ — это именно скармливать запросы целиком. Вот HTTP построен именно по этой схеме, и он прямо-таки фантастически удачен.
C>>Тогда будет ваша проблема с кучей мелких тривиальных операций.
S>Ее можно решить, введя в протокол понятие группы операций, запрашиваемых одним запросом.
Это тоже далеко не простое решение будет.

Здравствуйте, Sinclair, Вы писали:

A>>Вызываешь
A>>BeginTransaction()
A>>User user = CreateUser(...)
A>>CreateSite(user)
A>>CommitTransaction()
S>Непонятно, где я это вызываю. С клиента?

Да.

kuj>Вы знаете как зарабатывать деньги на открытых проектах? Поделитесь знаниями! :D
Очень даже неплохо живут люди. Типичная схема простая — есть open source проект, который много кому нужен (операционная система, фреймворк или даже просто библиотека). Есть крупные (часто военные) корпорации которые хотят использовать этот проект в своих решениях. Но связываться с open source они не хотят и зачастую не могут по навязанным свыше правилам — им не нужен код, за который никто не несёт ответственность. Поэтому появляются компании (в которых зачастую на очень даже неплохой зарплате сидят ведущие разработчики этого open source проекта) которые периодически делают fork из VCS open-source проекта в свою VCS и дальше продают код как свой. GPL они не нарушают поскольку продают всё с сорцами и модифицируют код сразу и в своей, и в open-source-ной VCS. Продают они фактически поддержку кода и ответственность за код. Продают за очень неплохие деньги, кстати.

Здравствуйте, Sinclair, Вы писали:

S>На доступном мне уровне развития науки, сие для БД-ориентированных приложений решительно невозможно. Даже не-БД тестировать "после малейшего изменения" нереально, т.к. банальная сборка мало-мальски сложного проекта начинает занимать больше времени

Странно. У нас такая схема работает без проблем. Время сборки измеряется минутами — с такой частотой коммиты идут редко. Зато я по каждому коммиту знаю его работоспособность.

Здравствуйте, adontz, Вы писали:

A>В любом случае звучит первспективно. Захотелось добавить в .Net

Будет. Но не раньше 2009 года.

Здравствуйте, Aviator, Вы писали:

A>Кто нибудь кстати рискнул написать свой query object ?

Я писал. Но не покажу, код коммерческий.

Здравствуйте, AndrewVK, Вы писали:

A>>В любом случае звучит первспективно. Захотелось добавить в .Net
AVK>Будет. Но не раньше 2009 года.

А при Путине ну никак нельзя написать?

Здравствуйте, AndrewVK, Вы писали:
AVK>Странно. У нас такая схема работает без проблем. Время сборки измеряется минутами — с такой частотой коммиты идут редко.
Примерно года полтора назад мы исследовали стоимость сборки. Даже чарт был построен. Сборку пооптимизировали, но всё равно проект большой, а веб приложения компилируются крайне медленно.
AVK>Зато я по каждому коммиту знаю его работоспособность.
Хорошо тебе.

Здравствуйте, Sinclair, Вы писали:

S>Примерно года полтора назад мы исследовали стоимость сборки. Даже чарт был построен. Сборку пооптимизировали, но всё равно проект большой, а веб приложения компилируются крайне медленно.

Ну да и черт бы с ним. Все равно среднее за сутки время между коммитами ИМХО будет существенно больше, чем время сборки.

Здравствуйте, adontz, Вы писали:

A>А при Путине ну никак нельзя написать?

При чем тут Путин?

Sinclair wrote:
> Примерно года полтора назад мы исследовали стоимость сборки. Даже чарт
> был построен. Сборку пооптимизировали, но всё равно проект большой, а
> веб приложения компилируются крайне медленно.
Так просто делайте тогда постоянную пересборку — как только предидущая
закончится, то начинаете новую с последней версии в репозитории.

Здравствуйте, AndrewVK, Вы писали:

A>>А при Путине ну никак нельзя написать?
AVK>При чем тут Путин?

2009 потому что

Здравствуйте, Cyberax, Вы писали:
C>Так просто делайте тогда постоянную пересборку — как только предидущая
C>закончится, то начинаете новую с последней версии в репозитории.
ТОгда у нас никогда не будет готовой версии

Здравствуйте, Sinclair, Вы писали:

C>>Так просто делайте тогда постоянную пересборку — как только предидущая
C>>закончится, то начинаете новую с последней версии в репозитории.
S>ТОгда у нас никогда не будет готовой версии
Почему? Предидущая построеная версия же будет оставаться

Здравствуйте, adontz, Вы писали:

AVK>>При чем тут Путин?

A>2009 потому что

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

A>>>http://www.google.com/search?q=sql+refactoring+tools
kuj>>Рефакторинг без юнит тестов? Удачи.

A>Мне вот интересно, что ты делаешь с нетестируемыми задачами?

А можно пример "нетестируемой задачи" ?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

A>>>Создаётся некоторая предопределённая база (схема+данные). Натравляется ХП. Проверяется, что данные после исполнения ХП соответствуют ожидаемым.
kuj>>Проверяете как? на глазок?

A>Нет, проверяется сравнением с эталоном. Не надо задавать дурацкие вопросы, ты меня утомляешь. Это не обсуждение это форменный флуд. Тебе кто-то платит за сообщения побуквенно? Наполни их не байтами, а энтропией.

К слову — чем бессмысленее набор байт, тем больше его энтропия

Здравствуйте, EM, Вы писали:

A>>Мне вот интересно, что ты делаешь с нетестируемыми задачами?
EM>А можно пример "нетестируемой задачи" ?

Да, уже говорили: пользовательский интерфейс (почти вся графика, нельзя же юнит тестировать распознавание образов), многопоточность (99% ошибок невозможно гарантированно воспроизвести), сетевой ввод-вывод (особенно штуки типа POP3/SMTP pipelining).