Как работать с типом Время в Workflow

[Anderyt]

думаю, это будет в сильной степени зависеть от того, как именно и что проверять.
смотрите.
сейчас и так каждый клиент проверяет новые сообщения, причем по умолчанию интервал проверки составляет 10 секунд - не так уж и редко, верно? и клиентов этих - более 120 одновременно (у нас). и ничего, все ок. сервер Бд на двух ксеонах с 2.5 метрами ОЗУ от этого в полном восторге. клиенты тоже вроде не жалуются
конечно, это объясняется тем, что запрос для проверки новых сообщений очень простой, идет обращение к одной таблице, в которой очень ограниченное число строк.
календари будут проверяться не так легко, это практически точно. но все равно - запрос будет быстрый, около 2-3 таблиц (в сочетании с автоматическим удалением записей старее 3-х месясцев - таблицы будут очень компактные ) и проверять наступление события можно раз в минуту - зачем чаще??
а сейчас, если делать напоминание на автосервере - это занимает слишком много ресурсов. как думаете, сколько таблиц должен связать автосервер, чтобы провести очередной цикл проверки? все эти переменные, значения переменных, карты, текущие позиции - это ж ужас! и все это ради какого то напоминания!
а автосервер - ОДИН, между прочим

[Александр]

а зачем нам сервер, таблицы и т.д. для напоминания? (в мобильнике же не стоит SQL сервер)
я понимаю когда нужна история привязанная к объекту и ее нужно где то централизованно хранить, а когда нет - достаточно к оболочке (Лоция) просто дописать/подключить планировщик
Запустили Лоцию Локально, настроились на Локальные часы, информацию по напоминанию храним в Локальных файлах.... и все, и нет проблем
И Автосервер отдохнет и пользователи расслабятся - только разработчики немного напрягутся

[Anderyt]

а зачем нам сервер, таблицы и т.д. для напоминания?

ну, например для того, чтобы иметь возможность записывать в календари пользователей определенные события, для этог оуже даже функции свои есть.
и к тому же, в БД уже есть структура, хранящая инфу из календарей

[Александр]

Предлагаю разделить понятия
1. Напоминание по объекту - привязка к объекту и(или) к пользователю - т.е. использование недоделанного календаря Лоции
2. Локальное напоминание - Напоминание самой оболочки - без привязки к структуре данных к серверу к пользователю базы и т.д.

Нам на данный момент больше нужны напоминания 2-го типа, чем 1-го

И по моему не стоит их смешивать т.к. 1-й тип это однозначно WorkFlow или нечто подобное а 2-й всего лишь сервис Windows

[gali]

ага, ясненько! Меня Андрей даже за "хоть кто-то" не держит

Я же сто лет назад возмущалась календарем!

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

У нас же возникал вопрос по календарю в следующем контексте. Я начала подсовывать Лоцию юзерам, и наиболее продвинутые (-тый) решил прощупать ее в качестве среды обитания. Послал что-то куда-то - нормально, попробовал записать в календарь свои встречи, дела - ждал напоминания. Не дождался. Громко плюнул на Лоцию рукой. И я его прекрасно понимаю.

[Anderyt]

ага, ясненько! Меня Андрей даже за "хоть кто-то" не держит

я имел в виду только то отношение участников форума к этой проблеме, которое они высказывали на самом форуме
так или иначе, прошу прощения - видимо, поторопился с выводами

[Александр]

Андрей ты так всех женщин распугаешь ктож нас будет вдохновлять

[gali]

"не боись!"
это я так, прикола ради

[Старик Крупский]

ктож нас будет вдохновлять

Как кто?!! Мы! Нежные и любящие мужчины

[gali]

пардон, если не в тему... т.е . не к вопросу вдохновления

здесь поднимался вопрос глобальности переменных
До вчерашнего дня тешила себя мыслью, что понимаю в этом что-то.
Вчера пришло глубокое разочарование.

Кто-нибудь может мне объяснить, как в Workflow работает разветвитель? Почему запись текста в глобальную переменную на переходах от разветвителя (по исполнителям) отсутствует в переменной на этапе объединителя?
И еще одно непонимание. На переходе к объединителю добавляю значение переменной в переменную типа массив (еще не понятно, почему это называется массив, когда реально просто список). В конкретной карте 2 исполнителя, т.е. ветка исполняется дважды. Делаю последовательно: прохожу ветку одним исполнителем, смотрю массив - там добавлено дважды одно и то же значение. Прохожу вторым - еще + 2 значения от второго исполнителя. Это что за фокус?

Я конечно покопаюсь сейчас в документации, но, если кому не влом объяснить, буду признательна.

[gali]

так, ясно. Один вопрос снимаю: почему в массив дважды добавляется - сама не доглядела.

[Старик Крупский]

На объединителе, наверное, ветка-победитель определяется как последняя пришедшая?

[gali]

Да. Последняя.
А в чем прикол?
Декларируется, что глобальная переменная хранит свое последнее значение. Я дозаписываю текст, не затираю.

У меня одна ветка сразу (по времени) приходит на объединитель (через автоматический этап). Смотрю в ней значение переменной:
1) текст до разветвителя + текст автоматической ветки.

Вторая ветка разветвляется по исполнителям. Вхожу одним из исполнителей:
2) текст до разветвителя + текст веток по исполнителям.

Прохожу ветку до конца - на объединителе добавляется текст с последнего перехода ветки по исполнителям, т.е.
3)=1)+текст с последнего перехода от исполнителя.

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

[Anderyt]

Разветвители это вообще очень загадочная форма жизни ) я ее до конца не изучил, по крайней мере, в смысле формирования значений переменных.. могу только посоветовать почитать практические рекомендации, главу про Сбор и просмотр виз и замечаний пользователей. там есть пара вариантов и вроде настраиваются ЛОКАЛЬНЫЕ переменные.
а массив или список... хм... но ведь есть массивы разной размерности, в том числе и одномерные

[gali]

Хочу понять механизм, чтобы в следующий раз не наступать.

Читала я эти практические. В некотором смысле пытаюсь реализовывать. Но это другой вопрос.
Мне же всегда чего-то не хватает. Сейчас хочу сделать на объединителе форму, в которой будет массив: исполнитель, задание, отчет. Причем, хочу, чтобы данные обновлялись по мере прихода на объединитель веток, ну, не совсем в "прямом эфире", но так, чтобы иметь более-менее реальную картину процесса, а не его результата.
Алгоритм на пальцах построила, теперь пытаюсь сообразить, как его реализовать имеющимися в лоции средствами.