Здравствуйте, Sinix, Вы писали: S>Если коротко, там обсуждалась только нагрузка на одного клиента, где-то рядом ещё обсуждали проблему локальной валидации и возможность сделать её декларативно силами EF.
Брр. Я под локальной валидацией всегда понимал ту, которую можно выполнить, оставаясь в рамках валидируемого объекта.
Ну то есть бывает еще и стейтлесс локальная валидация — для которой достаточно анализа одного свойства, она особенно интересна потому, что ее легко проносить в GUI ("логин должен начинаться с буквы и содержать буквы, цифры, или подчеркивания").
Глобальной я считал валидацию, которая затрагивает недетерминированное количество объектов. И мне крайне интересно, каким образом можно ее сделать без обращения к базе и без подтягивания в кэш клиента полной копии базы.
S>На глобальную валидацию никто вроде не замахивался.
Уникальность — типичное требование глобальной валидации. Именно на нее был сделан четкий замах вот в этом
постинге, разве нет? Там вроде датасет обеспечивал ее бесплатно, на rbtree индексах, и в базу не бегал. Как так?
S>Есть желание — напишу кучу других неправильных букв про то, чем хороши локальные проверки.
Да конечно, нужно только прояснить термины.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinix, Вы писали:
G>>Если пытаться вытягивать кучу связанных сущнстей из БД, то это может превратиться в огромную портянку заджойненых данных. G>>Передача сериализованных объектов бдет экономичнее.
S>Не дошло — вы про денормализацию? Бесполезно ведь для работы с данными, разве что только для отчётов... S>Или вы про грабли с выборкой части данных? Если второе — то решается кучей способов. Как правило заводитсся view типа UserOrders, который внутри себя определяет какие из заказов доступны текущему пользователю, и пишутся хранимки, что жойнят view c нужными таблицами (допустим, orders и orderdetails) и отдают нужные данные. S>С точки зрения клиента в базе вообще нет данных, кроме тех что он выгребает (на самом деле и тех нет по большей части — они живут в других базах).
Не, все гораздо проще.
Вы смотрели что отдает SQL Server кода вы пишите красивый Linq\eSQL\HQL запрос с несколькими джоинами? Если этим данные замапить на граф объектов и сериализовать даже в XML, то xml будет весить гораздо меньше, чем то что отдает MS SQL.
Поэтому в сценариях где требуется сокращение нагрузки на сеть имеет смысл отдавать данные через сервисы в виде сериализованных объектов, а не использовать TDS или датасеты.
Кроме того при правильной готовке ADO.NET Data Services можно в несколько раз сократить затраты на передачу за счет клиентского кеширования протокола HTTP.
Здравствуйте, gandjustas!
G>Вы смотрели что отдает SQL Server кода вы пишите красивый Linq\eSQL\HQL запрос с несколькими джоинами? Если этим данные замапить на граф объектов и сериализовать даже в XML, то xml будет весить гораздо меньше, чем то что отдает MS SQL. G>Поэтому в сценариях где требуется сокращение нагрузки на сеть имеет смысл отдавать данные через сервисы в виде сериализованных объектов, а не использовать TDS или датасеты. G>Кроме того при правильной готовке ADO.NET Data Services можно в несколько раз сократить затраты на передачу за счет клиентского кеширования протокола HTTP.
О! Вона вы про что
При такой постановке вопроса полностью согласен. С друой стороны это проблемы кривых запросов, не sql server'a. Такое по возможности лучше решать на месте, а не заводить пайп из костылей каждый из которых решает проблемы предыдущего.
По терминам у нас реальная солянка. В одну кучу свалились 4 юз-кейса:
1) stateless валидация ака ограничения на одну сущность — решается примерно одинаково абсолютно везде — IDataErrorInfo+IEditableObject в руки и паехали.
2) Проверка локального графа объектов. Реализуется датасетами при помощи uniqueConstraints. EF — своя viewModel
3) Проверка при/перед сохранением. Решается примерно одинаково — событиями при получении ошибок от сервера.
4) Глобальная проверка на каждый чих. Решается примерно одинаково — никак
4 нереализуемо в общем случае — всё сводится к когерентности локальных кэшей и обнаружении ошибок в _ещё не сохранённых данных_. Обычно ограничиваются проверкой при сохранении, т.е. 3.
п2 полезен в сценариях, когда каждый пользователь работает в своей песочнице и по возможности не лезет к другим. Если же взаимодействие необходимо, оно оформляется в реальный воркфлоу, а не делается через побочные эффекты
По ссылке мы обсуждали сценарий 2, речь шла о partial disconnected apps и об ограничениях внутри контекста — полная цитата:
G>Смотрю сгенерированные EF классы — оповещения будут.
Это оповещения на изменение свойств элемента. Они хороши для биндинга к конкретной сущности. Попробуйте отследить добавление/удаление/изменение любой сущности — причём именно те, что будут отражены в базе. У ObjectContext только одно событие — SavingChanges. Вы конеш можете проводить валидацию внутри сущностей, но это во-первых намекает о жирной модели. Во-вторых, вы не сможете так проверять сложные ограничения, что требуют доступа ко всему контексту. Или хотя бы отследить тот факт, что сущность поменяла родителя
Кстати, попробуйте реализовать ограничение на уникальность любого поля. EDM позволяет определить только один Key. Даже элементарное требование несуществования двух сущностей с одинаковыми именами уже требует приседаний. Напомню — нарушение ограничений должно обнаруживаться при попытке изменения сущности, чтобы можно было его отловить и исправить на месте. Вы внимательней присмотритесь к EDM. Как средство описания модели данных она довольно убога.
Здравствуйте, gandjustas, Вы писали: G>Вы смотрели что отдает SQL Server кода вы пишите красивый Linq\eSQL\HQL запрос с несколькими джоинами? G>Если этим данные замапить на граф объектов и сериализовать даже в XML, то xml будет весить гораздо меньше, чем то что отдает MS SQL.
Всё очевидным образом зависит от того, какова доля джойнов, и какова доля проекций. А также размер "основной" таблички. Если вытаскивать данные постранично, ограничивая размер результата осмысленными значениями, то, я боюсь, тяжко придется XML.
Поясняю мысль: вот у нас, допустим, список заказов. Нет, даже пусть это будет список позиций заданной накладной — так интереснее.
Потому что каждая строчка — почти чистый набор FK. И в ней, по идее, client-side join должен рулить со страшной силой.
Ну, давайте посчитаем:
1. Граф объектов.
Строки:
{
OrderID: 16
ItemID: 16
ProductID: 16
Quantity: 4
Price: 4
}
Итого: 56 байт. * 100 (строк).
Cобсно, продукты:
{
ProductID: 16
Name: 64 (средняя длина)
CategoryID: 16
Description: 400
Image: 16000
}
Итого: 16496. * 100 (ясен хрен, что все позиции ссылаются на различные товары)
Внимание, вопрос: кто победит?
G>Поэтому в сценариях где требуется сокращение нагрузки на сеть имеет смысл отдавать данные через сервисы в виде сериализованных объектов, а не использовать TDS или датасеты.
Вопрос мне не кажется столь уж однозначным. В большом-большом количестве случаев тащить повторно приджойненный кусочек (например, город где живет клиент) для каждой строки несущественно дороже таскания FK на этот объект. И это даже если не считать то, что объекты в графе будут тащить с собой тонны мусора — см. Description и Image в товаре.
Поэтому далеко не все графы шибко выиграют от сериализации. G>Кроме того при правильной готовке ADO.NET Data Services можно в несколько раз сократить затраты на передачу за счет клиентского кеширования протокола HTTP.
А вот это — строго правда. Поэтому RESTful Services рулят просто как водитель маршрутки в пробке.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Sinclair!
S>По терминам у нас реальная солянка. В одну кучу свалились 4 юз-кейса:
S>1) stateless валидация ака ограничения на одну сущность — решается примерно одинаково абсолютно везде — IDataErrorInfo+IEditableObject в руки и паехали. S>2) Проверка локального графа объектов. Реализуется датасетами при помощи uniqueConstraints. EF — своя viewModel
Я не понимаю, каков глубокий смысл проверять локальный граф объектов на уникальность.
S>4) Глобальная проверка на каждый чих. Решается примерно одинаково — никак
Прекрасно решается в асинхронной модели. Вон, гугл же успевает "глобально" проверять, нет ли поисковых запросов, похожих на то, что ты вводишь. Какие проблемы?
S>4 нереализуемо в общем случае — всё сводится к когерентности локальных кэшей и обнаружении ошибок в _ещё не сохранённых данных_.
Нереализуемо только в случае искусственного придумывания локальных кэшей. Все глобальные проверки делают только одно: проверяют "еще несохранённые" данные относительно "уже сохраненных".
Сумма транзакции проверяется на предмет превышения баланса; е-мейл проверяется на предмет уникальности; пароль проверяется на предмет совпадения с предыдущими семьюстами.
Никого не скребет, если ты открыл две формы, и в каждой из них набрал "списать 700р" при остатке в 1000. Им совершенно не нужно учитывать друг друга. Вот сделаешь одной сабмит — вторая потупит-потупит, да и выкинет ворнинг "ахтунг, приятель, деньги-то кончаются".
S>Обычно ограничиваются проверкой при сохранении, т.е. 3.
S>п2 полезен в сценариях, когда каждый пользователь работает в своей песочнице и по возможности не лезет к другим.
Непонятно. Если каждый пользователь работает в своей песочнице, то у вас нет общей базы и повода для конфликтов.
S>Если же взаимодействие необходимо, оно оформляется в реальный воркфлоу, а не делается через побочные эффекты
S>По ссылке мы обсуждали сценарий 2, речь шла о partial disconnected apps и об ограничениях внутри контекста — полная цитата:
Вот мне и непонятно — вы что, всеръез предлагаете пользователям в начале работы забирать к себе полную песочницу в виде датасета, а в конце ее записывать обратно?
Моей фантазии не хватает придумать приложение, где бы это работало мало-мальски эффективно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали: G>>Вы смотрели что отдает SQL Server кода вы пишите красивый Linq\eSQL\HQL запрос с несколькими джоинами? G>>Если этим данные замапить на граф объектов и сериализовать даже в XML, то xml будет весить гораздо меньше, чем то что отдает MS SQL. S>Всё очевидным образом зависит от того, какова доля джойнов, и какова доля проекций. А также размер "основной" таблички. Если вытаскивать данные постранично, ограничивая размер результата осмысленными значениями, то, я боюсь, тяжко придется XML.
Видимо я слишком категорично написал это утверждение.
S>Поясняю мысль: вот у нас, допустим, список заказов. Нет, даже пусть это будет список позиций заданной накладной — так интереснее. S>Потому что каждая строчка — почти чистый набор FK. И в ней, по идее, client-side join должен рулить со страшной силой. S>Ну, давайте посчитаем: S>1. Граф объектов. S>
S>Внимание, вопрос: кто победит?
Вообще говоря немного нечестное сравнение. В этом случае по заджойненным данным не получится восстановить граф объектов.
Да и не всегда джойниться будут разные строки.
G>>Поэтому в сценариях где требуется сокращение нагрузки на сеть имеет смысл отдавать данные через сервисы в виде сериализованных объектов, а не использовать TDS или датасеты. S>Вопрос мне не кажется столь уж однозначным. В большом-большом количестве случаев тащить повторно приджойненный кусочек (например, город где живет клиент) для каждой строки несущественно дороже таскания FK на этот объект. И это даже если не считать то, что объекты в графе будут тащить с собой тонны мусора — см. Description и Image в товаре.
Конечно правильные джоины и проекции будут рулить в любом случае. Только их еще писать надо.
В тоже время ADO.NET Data Services позволяют вытаскивать на клиента объекты данных при этом меньше забивая сеть, чем TDS.
Но это при тупом написании.
Здравствуйте, gandjustas, Вы писали: G>Вообще говоря немного нечестное сравнение. В этом случае по заджойненным данным не получится восстановить граф объектов.
Честное. Нахрена козе баян... тьфу, клиенту граф объектов? Ему нужна некоторая ViewModel, которую можно отобразить. В ней граф объектов — это излишество.
Граф объектов в ОРМ появился оттого, что уж очень дорого описывать типы "по месту". Поэтому ОРМщики привыкают обходиться тем, что есть — собирать View вручную. Упрощение этого процесса
G>Да и не всегда джойниться будут разные строки.
Не всегда. Я про одинаковые строки тоже написал — во многих случаях мы имеем star-join, где от каждого FK нам необходимо и достаточно иметь по одному полю.
В общем, для подбора убедительного примера с победой сериализации графв нужно еще постараться
G>Конечно правильные джоины и проекции будут рулить в любом случае. Только их еще писать надо.
А граф объектов что, волшебной силой на клиента прилетит и во View отобразится?
G>В тоже время ADO.NET Data Services позволяют вытаскивать на клиента объекты данных при этом меньше забивая сеть, чем TDS. G>Но это при тупом написании.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
G>>Да и не всегда джойниться будут разные строки. S>Не всегда. Я про одинаковые строки тоже написал — во многих случаях мы имеем star-join, где от каждого FK нам необходимо и достаточно иметь по одному полю. S>В общем, для подбора убедительного примера с победой сериализации графв нужно еще постараться
Если посмотреть реальные проекты, написанные среднестатистическим программистом, то и стараться особо не придется.
То что с нормальными выборками и проекциями можно сделать гораздо лучше я даже не сомневаюсь (и сам так делаю).
G>>Конечно правильные джоины и проекции будут рулить в любом случае. Только их еще писать надо. S>А граф объектов что, волшебной силой на клиента прилетит и во View отобразится?
Ага.
Я на демонстрации возможнойстей SL такое покаывал. Буквально 10 минут дела.
Здравствуйте, IB, Вы писали:
VD>> Статья 2004 года, а в 2008, как я понимаю как раз в области планов были серьезные изменения. IB>Серьезных не было. Там планомерные улучшения с 2000-й версии.
У меня другая информация. Кое что после выхода 2008-го устарело.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, VladD2, Вы писали:
IB>Нет, у меня реакция — "есть но непонятно зачем". На практике такое пожалуй только для поддержки легаси кода нужно, ну или какая-нибудь экзотика...
Гегаси?
Что уже есть устаревшие системы с триггерами на дотнете?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IB, Вы писали:
VD>>Гы. Любимый аргумент любителей скриптов. "А у нас юнит-тесты есть". IB>Дело не в скриптах, а в том, что юнит-тесты много где могут пригодится, в том числе и в БД.
Это понятно. Только они сами по себе не аргумент. Почти у всех есть юнит-тесты. Но это не делает не нужным комнтроль компилятора или грамотное проектирования. Это еще один вид защиты и средство отладки. Не более, и не менее того.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>У меня другая информация. Кое что после выхода 2008-го устарело.
Сейчас еще раз бегло просмотрел документацию по 2008-у — ничего супер нового. Основные изменения были в 2005, когда добавили ручек побольше для управления кешированием.
Здравствуйте, VladD2, Вы писали:
VD>Что уже есть устаревшие системы с триггерами на дотнете?
нет, есть клиент-серверные системы, с голой бд наружу, которым надо серверную логику прикрутить.
Здравствуйте, IB, Вы писали:
VD>>У меня другая информация. Кое что после выхода 2008-го устарело. IB>Сейчас еще раз бегло просмотрел документацию по 2008-у — ничего супер нового. Основные изменения были в 2005, когда добавили ручек побольше для управления кешированием.
Ты бы еще форум бегло почитал по этому поводу.
Там не много изменили, но реакция изменилась координально. Например, сброс кэша в 2005 все равно не приводил к нужному результату иногда, а в 2008 это изменили. Подробностей не помню, но точно помню, что кое-что поменялось.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IB, Вы писали:
VD>>Что уже есть устаревшие системы с триггерами на дотнете? IB>нет, есть клиент-серверные системы, с голой бд наружу, которым надо серверную логику прикрутить.
Сдается мне триггеры на полноценном языке могли бы пригодиться многим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Например, сброс кэша в 2005 все равно не приводил к нужному результату иногда, а в 2008 это изменили.
Сброс кеша всегда приводил к нужному результату — сбросу кеша. Это еще в 7.0 точно работало.. =)
VD>Подробностей не помню, но точно помню, что кое-что поменялось.
Рабинович насвистел? =)
Здравствуйте, VladD2, Вы писали:
VD>Сдается мне триггеры на полноценном языке могли бы пригодиться многим.
А мне сдается что нет. Ни триггеры, ни хранимки. Всю серьезную логику не связанную непосредственно с SQL-ем, все равно проще удобнее и правильнее делать в прикладном коде.
Ндя... По ходу читать с середины дискуссии вредно вообще.
Была цепочка:
-EF малоприменимо в десктоп-приложениях/
-почему?
-например, тяжело писать partial-disconnected apps-а/
-что такого в этих partial-disconnected? Вы неправильно готовите EF!
И панеслась. Если посмотреть на всю нашу ветку,видно что обсуждалась именно неприменимость EF как локального кэша данных из каропки. Из контекста одного сообщения это совершенно неочевидно.
Тем не менее распишу свою точку зрения.
Partial disconnected великолепнейше работает, когда есть куча рабочих мест, и каждый пользователь системы работает со своей порцией данных. Локальный кэш даёт возможность находить ошибки по мере редактирования, не пиная при этом сервер. То есть не кэш заводится ради проверок, а, наоборот, используется для валидации, которую можно провести локально. Локальные проверки ни в коем случае не подменяют собой проверок при сохранении. При такой расстановке акцентов пойдёт?
S>>4) Глобальная проверка на каждый чих. Решается примерно одинаково — никак S>Прекрасно решается в асинхронной модели. Вон, гугл же успевает "глобально" проверять, нет ли поисковых запросов, похожих на то, что ты вводишь. Какие проблемы?
Мы всё ещё говорим о проверках во время редактирования?
Подход гугла применим при редактировании примитивов. Проверка, что совместное редактирование сложного графа объектов не нарушает ограничений — безумно тяжкая вешь. Проще уж либо сразу блокировку на граф навесить, либо решать проблемы при внесении изменений.
Даже примитивное ограничение "сумма полей a и b не должна превышать 10" не подлежит моментальной глобальной валидации. Точнее, проверить-то можно, но это не даёт никаких гарантий, что при сохранении это ограничение не будет нарушено новыми изменениями. Зато сервер будет перегружен кучами мелких запросов.
Чтобы _гарантированно_ проверить, что одновременное редактирование не приведёт базу в рассогласованное состояние, нам надо знать обо всех изменениях, ещё не внесённых в базу. Дальше нам надо каким-то образом сэмулировать внесение всех этих изменений и проверить все ограничения. Не слишком большая работа для организация "умного" подсвечивания ошибок?
S>Сумма транзакции проверяется на предмет превышения баланса; е-мейл проверяется на предмет уникальности; пароль проверяется на предмет совпадения с предыдущими семьюстами. S>Никого не скребет, если ты открыл две формы, и в каждой из них набрал "списать 700р" при остатке в 1000. Им совершенно не нужно учитывать друг друга. Вот сделаешь одной сабмит — вторая потупит-потупит, да и выкинет ворнинг "ахтунг, приятель, деньги-то кончаются".
Здесь вы говорите о сценарии 3 — проверке при сохранении. Как уже писал — она реально необходима. Тем не менее, каждая ошибка, возникающая при такой проверке — неявный признак косяка в проектировании UI. Чтобы избежать подобных проблем, можно например ввести проверку, что товарищ уже не залогинился где-либо ещё.
S>>п2 полезен в сценариях, когда каждый пользователь работает в своей песочнице и по возможности не лезет к другим. S>Непонятно. Если каждый пользователь работает в своей песочнице, то у вас нет общей базы и повода для конфликтов.
... S>Вот мне и непонятно — вы что, всеръез предлагаете пользователям в начале работы забирать к себе полную песочницу в виде датасета, а в конце ее записывать обратно? S>Моей фантазии не хватает придумать приложение, где бы это работало мало-мальски эффективно.
Ух... как всё вверх ногами-то перевернульось!
Попробуем ещё раз. У нас есть некоторая база данных. Есть несколько пользователей, которые одновременно вносят изменения. Диапазоны доступных данных у пользователей не будут одинаковыми — например, из-за ограничений доступа.
При одновременном редактировании одних и тех же сущностей неизбежны конфликты. Поэтому работа пользователей организуется таким образом, чтобы один товарищ не мешал другому — это чисто административные меры. Отсюда и берутся "почти непересекающиеся" песочницы.
Тем не менее, при редактировании своих данных каждый товарищ может внести сложные ошибки, которые можно обнаружить, только проверив весь граф объектов. Если граф уже есть на клиенте (а часть его скорее всего там есть, раз уж мы его изменяем), то по возможности такие ошибки надо проверять на месте.
На всякий. Речь идёт не о вытягивании всей базы на клиента, а об организации работы так, чтобы каждый пользователь мог работать с небольшим сегментом данных и не заботиться о том, что он кому-то что-то поломает.
Если мои неправильные буквы вызовут вопросы и на этот раз — придётся признать что я совершенно не умею выражать свои мысли и свернуть дискуссию
Здравствуйте, Sinix, Вы писали:
S>Partial disconnected великолепнейше работает, когда есть куча рабочих мест, и каждый пользователь системы работает со своей порцией данных. Локальный кэш даёт возможность находить ошибки по мере редактирования, не пиная при этом сервер. То есть не кэш заводится ради проверок, а, наоборот, используется для валидации, которую можно провести локально. Локальные проверки ни в коем случае не подменяют собой проверок при сохранении. При такой расстановке акцентов пойдёт?
Я продолжаю непонимать. Слишком абстрактно написано. Какие именно проверки "можно провести локально"? Неоднократно звучал пример про уникальность. Я в очередной раз прошу объяснить, каким образом это собирается работать.
Поясню — по-видимому, мои вопросы как-то не так сформулированы:
1. Вот у нас есть N объектов, каждый из которых должен быть уникален по какому-то признаку.
2. Вот у нас есть локальный кэш, в котором лежат K объектов
3. И вот пользователь изменяет один из этих К объектов.
Какой смысл в локальной проверке на уникальность? Как вы обеспечите достаточно низкую вероятность того, что дубликат есть среди N-K объектов?
S>Мы всё ещё говорим о проверках во время редактирования?
Да. S>Подход гугла применим при редактировании примитивов. Проверка, что совместное редактирование сложного графа объектов не нарушает ограничений — безумно тяжкая вешь. Проще уж либо сразу блокировку на граф навесить, либо решать проблемы при внесении изменений.
Я не очень понимаю, что такое "сложный граф объектов". Какого рода ограничения вы хотите проверять? В RDBMS приняты всего четыре типа ограничений:
1. Ограничения на скалярные вводимые значения — малоинтересны нам
2. Ограничения уровня строки
3. Ограничения foreign key
4. Ограничения uniqueness
Я могу придумать еще много видов, но в большинстве случаев они сведутся к развитию 3 и 4. Ну, например, foreign key будет проверять не наличие значения в целой таблице, а в каком-то подмножестве.
S>Даже примитивное ограничение "сумма полей a и b не должна превышать 10" не подлежит моментальной глобальной валидации.
А зачем тут глобальная валидация? Мы же это обсуждали. Почему в ответ на вопрос про ограничения типа 3 и типа 4 приводится пример типа 2? S>Точнее, проверить-то можно, но это не даёт никаких гарантий, что при сохранении это ограничение не будет нарушено новыми изменениями.
Правильно. Это совершенно корректная точка зрения — до коммита транзакции вообще никаких гарантий дать нельзя. Такова жестокая природа.
Но я совершенно согласен с тем, что это не повод вообще не выполнять проверок в процессе ввода. Надо делать так, как удобно пользователю.
S>Зато сервер будет перегружен кучами мелких запросов.
Да, это плохо, но я в упор не вижу, каким образом можно провести валидацию без обращения к серверу. Я не против нее — только объясните уже, какой магией это заработает!
S>Чтобы _гарантированно_ проверить, что одновременное редактирование не приведёт базу в рассогласованное состояние, нам надо знать обо всех изменениях, ещё не внесённых в базу.
НЕТ!!!!
Я же написал русским по белому: каждое изменение проверяется в предположении, что оно — единственное.
S> Дальше нам надо каким-то образом сэмулировать внесение всех этих изменений и проверить все ограничения. Не слишком большая работа для организация "умного" подсвечивания ошибок?
Не нужно ничего эмулировать. Приведите пример, где бы это потребовалось.
S>Здесь вы говорите о сценарии 3 — проверке при сохранении.
Нет, я говорю именно о проверке до сохранения. Вот я набрал в форме "700р". Клиент сбегал проверил — баланс на счету достаточный, можно нажимать Ok. Но я не нажимаю. Значит, клиент будет вынужден иногда бегать на сервер за обновлениями. Почему? Да потому, что могло быть наоборот — я набрал "2000р". Да, я в курсе, что в момент открытия формы там было 1000. Но я знаю, что с минуты на минуту мне на счет положат еще 5000р. Клиент не должен запрещать мне попытку провести деньги — он может быть не в курсе, что там происходит на другом конце. S>Как уже писал — она реально необходима. Тем не менее, каждая ошибка, возникающая при такой проверке — неявный признак косяка в проектировании UI.
Какой-то он очень неявный, этот признак. Я не верю в то, что возможно спроектировать UI с гарантией выполнения таких требований. Он бы потребовал удержания транзакции на уровне serializable с самого начала перехода в режим редактирования и до самого коммита. Технически это возможно, но будет очень-очень хреново масштабироваться.
Поэтому на мой взгляд имеет смысл несколько снизить требования к UI. И я полагал, что именно этот вариант мы и обсуждаем — клиент старается сделать как можно больше, но ничего не гарантирует до сохранения.
S>Чтобы избежать подобных проблем, можно например ввести проверку, что товарищ уже не залогинился где-либо ещё.
Зачем? Кому нужны эти ограничения?
S>Попробуем ещё раз. У нас есть некоторая база данных. Есть несколько пользователей, которые одновременно вносят изменения. Диапазоны доступных данных у пользователей не будут одинаковыми — например, из-за ограничений доступа.
Прекрасно. S>При одновременном редактировании одних и тех же сущностей неизбежны конфликты. Поэтому работа пользователей организуется таким образом, чтобы один товарищ не мешал другому — это чисто административные меры. Отсюда и берутся "почти непересекающиеся" песочницы.
Но ведь ограничения-то выходят за пределы песочниц! Если мы говорим об уникальности в пределах песочницы — так и говорите. Но у меня сложилось впечатление, что речь идет о глобальной уникальности.
S>Тем не менее, при редактировании своих данных каждый товарищ может внести сложные ошибки, которые можно обнаружить, только проверив весь граф объектов. Если граф уже есть на клиенте (а часть его скорее всего там есть, раз уж мы его изменяем), то по возможности такие ошибки надо проверять на месте.
Вот мне и непонятно, каким образом вы выполняете "проверку всего графа", когда на клиенте скорее всего его часть.
S>На всякий. Речь идёт не о вытягивании всей базы на клиента, а об организации работы так, чтобы каждый пользователь мог работать с небольшим сегментом данных и не заботиться о том, что он кому-то что-то поломает.
Это понятно. Намерения ваши были ясны еще с первого постинга. Я просто не понимаю, как вы собираетесь их выполнять.
S>Если мои неправильные буквы вызовут вопросы и на этот раз — придётся признать что я совершенно не умею выражать свои мысли и свернуть дискуссию
Не нужно выражать мысли. Вы просто на вопросы ответьте.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Мы уже победили, просто это еще не так заметно...
