DVM ©   (09.01.12 18:55) [60]

Автоматическое обновление может быть использовано лишь там, где:
1) этого хочет клиент
2) это технически возможно

vuk ©   (10.01.12 00:34) [86]


> А вот особенно будет весело, если запись перестанет условию
> фильтра какого-нибудь удовлетворять. :)


У нас такое бывает. Но:
1) если запись была в процессе редактирования, то она не могла поменяться, потому как при входе в режим редактирования она локируется (не в БД, а через RTMP) и никакой другой клиент не может ее редактировать
2) иначе позиция курсора не меняется
В результате, 1 и 2 приводят к тому, что позиция курсора никогда не меняется :)

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


У нас разное понимание отображения нового. Не должен экран "прыгать", подсвечивая красным измененные строки, а фиолетовым измененные значения. Экран остается таам же, где он был. Если в текущем экране есть измененные строки, они актуализируется. Без всяких подсвечиваний (если не требуется по ТЗ, конечно). Если очень надо узнать именно изменения, то можно где-то добавить статус "Изменилось N строк" с кнопкой "Просмотреть изменения"

> (ключ изменился. помним?)


Вот люди. Вместо того, чтобы нормально БД проектировать, пытаются отказаться от автообновления. Типа фильтр - это плохо, потомоу что очень медленно искать данные в текстовом файле размером 2 Tb. Не должен ключ меняться никогда. Если естественный ключ меняется, значит, надо было делать суррогатный.

> Зависимость осталась, но сделал (сам делал этот момент)
> так, что при перезаписи уже измененного поля выходит окно,
>  где написано что запись с момента взятия в работу была
> изменена


А не удобнее ли было бы пользователям, если бы при редактировании строки другие пользователи не могли бы инициировать редактирование той же строки?

> Не понял. У нас происходила заморозка (резервирование) товара при любых операциях ...
что тут не понятного? сам описываешь классическую учетную систему, невозможность "скрестить ежа с ужом". а по логике автообновлиния низя, никаких резервирований, никаких транзакций с захваченным "куском" данных, никаких блокировок. оно же должно меняться понимаешь? меняться в зависимости от того что кто-то меняет это в сети (как в фильмах с постепенно исчезающим с экрана документом, при удалении его ТАМ).
я как раз это пытаюсь "донести", а ты это же приводишь как аргумент возможности, типа залокируйте и все ок, но это против постановки автообновления как "коня в вакууме", это уже частности по "а зачем/для чего конкретно".

> а по логике автообновлиния низя, никаких резервирований,
>  никаких транзакций с захваченным "куском" данных, никаких
> блокировок. оно же должно меняться понимаешь? меняться в
> зависимости от того что кто-то меняет это в сети (как в
> фильмах с постепенно исчезающим с экрана документом, при
> удалении его ТАМ).
> я как раз это пытаюсь "донести", а ты это же приводишь как
> аргумент возможности, типа залокируйте и все ок, но это
> против постановки автообновления как "коня в вакууме", это
> уже частности по "а зачем/для чего конкретно".


Пока не донес :) Не понимаю до сих пор. Почему "по логике автообновлиния низя, никаких резервирований,  никаких транзакций с захваченным "куском" данных, никаких блокировок"? По логике нельзя позволять двум пользователям редактировать одни и те же данные, независимо от наличия автообновления. Поэтому локировка обязана быть. Как показывает мой (и не только) опыт, автообновления не препятствует этому, даже наоборот, помогает с локировкой.  Можно конкретнее? Приведи, пожалуйста, пример, когда без автообновления работает, а с ним - проблемы?

> Приведи, пожалуйста, пример, когда без автообновления работает,
>  а с ним - проблемы?


Кстати, с точик зрения формальной логики, этого будет недостаточно, чтобы доказать, что автообновление всегда плохо. А вот мне достаточно привести пример, когда автообновление реально помогает (не с read only данными), и я его уже приводил, а он опровергнут не был.

to Компромисс ©   (10.01.12 10:53) [102]:

> У нас такое бывает. Но:1) если запись была в процессе редактирования,
>  то она не могла поменяться, потому как при входе в режим
> редактирования она локируется (не в БД, а через RTMP) и
> никакой другой клиент не может ее редактировать2) иначе
> позиция курсора не меняетсяВ результате, 1 и 2 приводят
> к тому, что позиция курсора никогда не меняется :)

А вот ситуация:
1. Некто Петя получил список каких-то операций в определенном состоянии и сидит их спокойно изучает безо всякого редактирования.
2. Некто Вася изменяет состояние операции, которую в данный момент просматривает Петя.

Вопрос. Что должно произойти у Пети, если работает система автообновлений?

vuk ©   (10.01.12 11:08) [108]


> А вот ситуация:
> 1. Некто Петя получил список каких-то операций в определенном
> состоянии и сидит их спокойно изучает безо всякого редактирования.
>  
> 2. Некто Вася изменяет состояние операции, которую в данный
> момент просматривает Петя.
>
> Вопрос. Что должно произойти у Пети, если работает система
> автообновлений?


Если Петя выполнил операцию получения отчета, то ничего, потому как он сидит в каком-нибудь Excel или PDF reader. Если Петя изучает список в том же режиме, что используется для обычной работы (редактирования), то он увидит новое состояние. У нас так сделано, во всяком случае, и никто не жалуется. Если очень хочется, можно вынести настройку автообновления (чекбокс) в интерфейс и пусть пользователь сам решает, что ему надо.

> А вот ситуация:
И что такого в этой ситуации? ситуация как ситуация, ну актуализировались данные, ну и что, волосы, как говорили тут, рвать сразу надо?
У нас в такой ситуации не Вася, а несколько десятков сервисов в режиме 24/7, и все волосатые до сих пор.

Читаешь и складывается ощущение, мол кто уже столкнулся с необходимостью, то криминала не видит, остальные в панике. :)

to Компромисс ©   (10.01.12 11:21) [109]:

> Если Петя изучает список в том же режиме, что используется
> для обычной работы (редактирования), то он увидит новое
> состояние.

Повторяю еще раз. Состояние - критерий выборки у Пети. Состояние изменилось. После обновления увидит ли Петя запись, которую изучал до изменения состояния?

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

> Повторяю еще раз.
не старайся, не поймут, им это не выгодно...

vuk ©   (10.01.12 11:27) [112]
Повторяю еще раз. Состояние - критерий выборки у Пети. Состояние изменилось. После обновления увидит ли Петя запись, которую изучал до изменения состояния?

Странный вопрос. Автообновление не реализовано автоматически каким-то стандартным компонентом, поэтому поведение зависит от того, как мы его реализуем. А реализовать мы можем по-разному, в зависимости от ТЗ. Можно запретить удаление из отображаемого набора текущей строки (кстати, а зачем, ведь строки уже нет), можно показывать старое ее значение при редактировании другим пользователем (кстати, а зачем, ведь зстарые начения уже не вернешь, хотя...), можно показывать новое значение (самое правильное).
В том же Flex типичная реализация проста до безобразия - меняется элемент коллекции (после поиска по ключу) и всё... Даже рефреш вызывать не надо :)

sniknik ©   (10.01.12 11:29) [114]

> > Повторяю еще раз.
> не старайся, не поймут, им это не выгодно...


Печально, что сложилось такое впечатление... Я действительно пытаюсь понять. Возможно, есть какая-то проблема, но в моих примерах почему-то никто ее не предъявляет к рассмотрению.

> вижу ограничения той проги/оутлука/чата (обновление на дополнения
> одной таблицы), по сравнению с тем что я обычно в базах
> использую/как с ними работают...


У нас работа клиента вообще не завязана на БД и тем более какие-то там таблицы. И это правильно ИМХО. Вон мы недавно на nosql перенесли кое-что, клиентов даже менять не пришлось :) Data Transfer Object - наше всё :)

Компромисс ©   (10.01.12 11:40) [115]:

>  Можно запретить удаление из отображаемого набора текущей
> строки

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


>  (кстати, а зачем, ведь строки уже нет)

Строка есть, но в другом состоянии. Это повод отобрать у Пети возможность изучать операцию?


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

Дело не в том, какое состояние строки видит пользователь, а в том, видит ли он строку вообще.


> можно показывать новое значение (самое правильное).

Новое значение чего? Состояние строки не соответствует критерию выборки.


> В том же Flex типичная реализация проста до безобразия -
>  меняется элемент коллекции (после поиска по ключу) и всё.
> .. Даже рефреш вызывать не надо :)

Не надо путать рабочий процесс пользователя с внутренними механизмами библиотек.

vuk ©   (10.01.12 11:59) [117]

На все вопросы - один ответ: в зависимости от ТЗ. У нас, например, редактируемая запись отображается всегда, даже если в процессе редактирования она перестает удовлетворять фильтру.
На казуистику тратить время неохота, уж извините.

to Компромисс ©   (10.01.12 12:07) [118]:

> У нас, например, редактируемая запись отображается всегда,
>  даже если в процессе редактирования она перестает удовлетворять
> фильтру.

Я специально сказал, что запись не редактируется. :)


> На казуистику тратить время неохота, уж извините.

Это не казуистика, это вопросы, которые возникают сразу, как только кто-то говорит "а давайте прикрутим автообновление!". По крайней мере у меня возникают. Фигня в том, что однозначного ответа на них нет. Потому, что там, где нужно активное взаимодействие с пользователем в системах обработки данных, мы либо ломаем кому-то рабочий процесс либо сводим смысл автообновлений к нулю.