Пользовательский интерфейс и транзакции

Цитата Akina @ 16.04.13, 05:00

Цитата JoeUser @ 15.04.13, 16:19

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

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

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

Цитата JoeUser @ 16.04.13, 09:43

В случае "временных таблиц" навскидку и не берусь определить алгоритм подобного.

Не понял... в случае временных таблиц в них по-сырому можно лить любую хрень произвольного уровня несогласованности. Принимая команду на слив данных в боевые таблицы - проводить произвольное количество проверок (и автокорректировок!) любого уровня тяжести. И всё это - не затрагивая в принципе основной системы и данных в ней.
И только когда данные рафинированы - они одним быстрым транзакционным плевком загоняются в рабочий массив.
При такой технологии сам по себе откат транзакций - операция ну очень редкая. И связанная, как правило, отнюдь не с самими данными.

Сообщение отредактировано: Akina - 16.04.13, 11:07

Пример:

* Открыта транзакция
* Пользователь создает запись N4 таблицы T1
* Пользователь блокирует запись запись N4 таблицы T1
* Пользователь блокирует запись запись N8 таблицы T2
* Пользователь модифицирует запись N8 таблицы T2

* Пользователь начал создавать запись-связку в таблице T3
... ушел курить на 30 мин
... пришел
* Пользователь записал связку в таблице T3
* Пользователь закоммитил транзакцию (или откатил)
(Во время перекура хотели удалить запись N8 таблицы T2, была заблокирована - у них не вышло. Все в шоколаде.)

Как такое можно (и нужно ли) реализовать в виде временных таблиц?

Пффф... ты, блин, читаешь, что я пишу? Всё, что ты расписываешь, включая перекур, происходит в личном временном пространстве юзера. Все остальные тупо не в курсе, что он там чёта суёт в таблицы... и только когда он всё подготовил, когда отработала процедура проверки данных (в т.ч. и на согласованность подготовленных данных и информации в основных таблицах!), он за пару миллисекунд одной транзакцией вплёвывает все подготовленные и проверенные данные во все три таблицы, с необходимыми корректировками связей. Хотел бы я видеть того умельца, который посередь этой транзакции успеет попробовать "удалить запись N8 таблицы T2"... тем более что один хрен у него ничего не выйдет.

Понятно .... т.е. ты предлагаешь:

- строить дерево проверок
- поднапрячь базу на эти проверки
- и записать одним плевком

а если проверки сфэйлились ... че делать с данными, которые пользователь набирал 3 часа?

Добавлено 16.04.13, 11:37

Цитата Akina @ 16.04.13, 11:24

Хотел бы я видеть того умельца, который посередь этой транзакции успеет попробовать "удалить запись N8 таблицы T2"... тем более что один хрен у него ничего не выйдет.

Я тот умелец
Заблокирую запись N8 таблицы T2 и пойду курить, приду и удалю.
А запустишь ты до или после моего перекура - не важно, важно что ты с моей блокировкой не разберешься и придется твой "плевок" как-то обрабатывать.

Цитата JoeUser @ 16.04.13, 11:29

а если проверки сфэйлились ... че делать с данными, которые пользователь набирал 3 часа?

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

Добавлено 16.04.13, 11:40

Цитата JoeUser @ 16.04.13, 11:29

Я тот умелец
Заблокирую запись N8 таблицы T2 и пойду курить, приду и удалю.
А запустишь ты до или после моего перекура - не важно, важно что ты с моей блокировкой не разберешься и придется твой "плевок" как-то обрабатывать.

Чёрта с два.
Эта запись появится лишь во время быстрой транзакции, до её начала эта запись не существует, и начать удалять тебе тупо нечего. Но если ты даже успеешь вклиниться в эту миллисекунду - блокировки тебя пошлют лесом. А после коммита моей транзакции - тебя пошлёт лесом подсистема целостности.

Сообщение отредактировано: Akina - 16.04.13, 11:41

Цитата Akina @ 16.04.13, 11:37

Чёрта с два.
Эта запись появится лишь во время быстрой транзакции, до её начала эта запись не существует, и начать удалять тебе тупо нечего.

Цитата JoeUser @ 16.04.13, 11:19

Пример:
* Пользователь блокирует запись запись N8 таблицы T2
* Пользователь модифицирует запись N8 таблицы T2

1) Я блокирую запись N8 таблицы T2
2) Возможно удалю, возможно просто изменю, но пока блокировка висит
3) Ты редактируешь, а потом пытаешься залить одной транзакцией

Цитата JoeUser @ 16.04.13, 12:01

3) Ты редактируешь, а потом пытаешься залить одной транзакцией

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

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

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

Попробую показать на еще одном примере:

Пользователь строит некое генеалогическое дерево, последовательно вызывая 378 диалоговых окон (каждое окно вызывает окно наследник и ждет его закрытия с готовыми данными, или отменой). На 78 окне ты выбрал скажем в одном из полей значение "Мuнск", ну и пошел редактировать дальше, добравшись до 378 окна.

В это время оператор увидел ошибочную запись - в слове "Мuнск" вместо "и" лат буква "u" - он удалил из справочника сей термин. Потом через час решил добавить правильный "Минск". Добавил (но Id у термина уже другой).

Пришло время сохранения твоих данных. Все диалоги успешно закрыты. Пошли твои проверки, обломились на отсутствии термина. Судя по твоему принципу ты предложишь пользователю "Ретри Аборт Игноре" ... куда 378 диалогов с набитой информацией девать - во временных таблицах, ясный перец. А как пользователю данные править, ошибки находить? 78 диалогов пробегать?

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

Цитата JoeUser @ 16.04.13, 12:28

Судя по твоему принципу ты предложишь пользователю "Ретри Аборт Игноре" ... куда 378 диалогов с набитой информацией девать - во временных таблицах, ясный перец. А как пользователю данные править, ошибки находить? 78 диалогов пробегать?

А вот тут ты не понял... пользователь получит диагностику:

У тебя в 78 окне в поле Город был введён какой-то Мuнск, такой фигни в справочнике нетути... и вот тебе на выбор варианты:
1) Щя я тебе открою поле, и ты там откорректируешь этот самый Мuнск на чёнить вменяемое;
2) Давай я тебе покажу, чё там валяется готового в справочнике (сортируя по расстоянию Левенштейна, чтобы далёко не бегать, а коли хочешь по алфавиту - сам пересотиришь), выберешь;
3) Это не ты дурак, а остальные дураки, так что впишем мы в таблицу этот город Мuнск и забубеним на него сцылочку.
Ну и стандартные 4) "Экспорт на будущее, завтра разберёмся" и 5) "Идёт оно лесом".

И в итоге: 5 пунктов ... вместо 0 пунктов

Не пять, а один из пяти. И устойчивость к любым пакостям - ответственность всё равно переваливается на оператора.

Цитата Akina @ 16.04.13, 13:08

Не пять, а один из пяти. И устойчивость к любым пакостям - ответственность всё равно переваливается на оператора.

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

Цитата JoeUser @ 16.04.13, 13:41

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

А в моём что, развен не так же?

Если заблокировал, тогда смысл последующих чеках? Блок и так обеспечивает тебе валидность.