Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 CheckOut с последющим Undo или CheckIn  [new]
RubinDm
Member

Откуда:
Сообщений: 461
Есть база, app-server и web-client, который работает с базой только через app-server и про SQL ничего знать не знает. В базе - таблица с записями о документах (ID, дата, номер и другие поля). Надо реализовать механизм, который даст возможность работы с документами в стиле CheckOut с последющим Undo или CheckIn. Подразумевается, что между CheckOut и CheckIn могут быть (и обязательно будут) срывы подключений к базе (ибо application-server коннекции долго открытыми старается не держать). Каждый раз, когда пользователь открывает документ на редактирование, он НЕявным образом делает CheckOut документа. Далее пользователь вносит в документ изменения, но еще НЕ check-in'ит эти изменения. Далее пользователь должен сохранить документ (явным образом), в результате чего app-server НЕявным образом сделает CheckIn документа. Как уже было сказано ранее, между CheckOut и CheckIn будут штатные срывы подключений к базе, например, узер после внесения изменений и БЕЗ явного сохранения документа закрыл брозер (check-in'а со стороны app-servera не было). По возвращении узера и его авторизации, app-server восстановит его сессию и должен будет показать узеру документ в том недопиленном виде, в котором узер его оставил закрыв броузер. Очевидно, что в виду срыва подключений app-сервера к SQL, организовать такой бехейвор на уровне открытых SQL транзакций низя (да и тупо это). Как следствие, нарисовалась монструозная механизма хранения промехуточных результатов редактирования документов на уровне самого app-сервера. Все бы ничего, но app-server генерит SQL запросы, причем сложные, с джойнами, пивотами, фильтрами, сортировками, хинтами, все приблуды в полный рост... и зачастую построить SQL просто невозможно только потому, что он (SQL запрос) по определению должен быть завязан на результаты промежуточных редактирований от узера, которых на уровне SQL просто нет. С простейшими подстановками в SQL значений из отредактированных полей документов (в виде SQL-констант) app-server легко справляется, но это меньшинство из возможных случаев. В итоге команда начинает задумываться о том, как бы так сделать, чтобы все документы (читай "версии документов") хранились бы на сервере. Придумали добавить в табличку поле с номером сессии, к которой принадлежит данная версия документа. Если сессия не указана - значит это закомиченная версия, которую видят все. Это пока только придумали (долго не думали), но не делали, т.к. пока не представляем себе, насколько фигово отыграет на планах появление в SQL-генерации новых доп. фильтров аля where SessionId = @CurrentSession or SessionId = 0 order by SessionId desc. Хочется что-то такое придумать, чтобы можно было обойтись БЕЗ явных фильтров сессии, чтобы сиквел САМ понимал, что select * from [что-то-там] какбэ подразумевает select только моих или общих (при отсутствии моих личных) версий документов. Ну и понятно, что очень хочется, чтобы индексы не перестали отыгрывать. + мы пока плохо понимаем, как select top (1) c фильтрами SessionId = @CurrentSession or SessionId = 0 и с сортировками order by SessionId desc можно использовать в джойнах, разве что через cross apply. Как такие конструкции отыграют в больших количествах (в 50% от всех джойнов практически во всех запросах) мы также не можем предсказать. Хочется понять, в том ли вообще направлении мы думаем (мучают сомнения). Кто как такие задачки решал? ORMы - это понятно, но с ними тож сложности возникают, особенно если учесть что наша мега-система не одну мировую пережила, заслуженная писионерка, и бизнес-логики на ней как медалей немерено, нахрапом такую бабушку мы не перепишем.
11 дек 13, 04:37    [15274542]     Ответить | Цитировать Сообщить модератору
 Re: CheckOut с последющим Undo или CheckIn  [new]
Ruuu
Member

Откуда: Иркутск
Сообщений: 4272
RubinDm,

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

В простейшем виде можно для документа добавить поля Редактирующий_пользователь и Время_начала_редактирования. Перед началом редактирования документа пользователь должен запросить блокировку, проверяем свободна ли она, или этот пользователь уже поставил блокировку, соответственно либо разрешаем либо отклоняем запрос на блокировку.
Добавить джоб, который снимает старые блокировки.

Почитайте эту статью, здесь этот вопрос достаточно подробно разобран:
Управление совместным изменением данных
11 дек 13, 05:14    [15274566]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить