Support Forum

[a-b-c]

Мы используем связку SA 64 + PostgreSQL 8.4, задача - реализовать регулярные бекапы самой TS, базы данных и загруженных файлов.
Насколько я знаю, сейчас TS работает таким образом, что бекап базы данных можно делать лишь при выключенной TS (из-за системы кэшей). При перезагрузке TS теряются сессии пользователей, что для этих самых пользователей не очень удобно. Можно ли обойти данное неудобство, чтобы и бекап можно было сделать, и сессии не потерять?
Какие я вижу варианты:
1) сохранение сессий при выключении TS и их подгрузка при включении TS.
2) настройка TS так, чтобы по команде (по внутреннему расписанию, или по SOAP) TS сбрасывала весь кэш в БД (т.е. подготовавливала БД к бекапу), отчитывалась о выполнении и ждала команды для продолжения работы (опять же, по SOAP или по внутреннему расписанию, например, 5 минут)

Пока в голову других вариантов не приходит.
В пользу 1 варианта могу привести случай незапланированного выключения TS (по внутренним или внешним обстоятельствам), да и скорее всего его проще реализовать.

[Petr]

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

[a-b-c]

Пётр, не очень понял про включенную тс, можете поподробней расписать сценарий такого бекапа?

[Petr]

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

[a-b-c]

Как я понял, мы ничего не потеряем, если будем делать бекапы при запущенной TS? Тогда всё отлично, бекапы мы планируем делать стандартными средствами PostgreSQL по расписанию, в sman эта функциональность нам не нужна.
А что насчет сохранения сессий между перезагрузками? У нас в последнее время перезагрузка достаточно часто происходит, сохранение сессий очень бы пригодилось.

[Petr]

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

[a-b-c]

Тогда прошу занести данную фичу в список потенциальных фич, чтоб внести, когда будет такая возможность.
Кстати, можно ли посмотреть на список планируемых к реализации фич? А то по некоторым мы здесь уже общались, пришли к выводу, что пока рано - не потерялось ли? Просто потребность есть, еще раз предлагать как-то неудобно. Не планируется ли сделать что-нибудь типа голосования по фичам? Например, как это сделано в dropbox'е, список фич, сколько голосов, в режиме ожидания/реализации/готово.

[admin]

Тогда прошу занести данную фичу в список потенциальных фич, чтоб внести, когда будет такая возможность.
Кстати, можно ли посмотреть на список планируемых к реализации фич? А то по некоторым мы здесь уже общались, пришли к выводу, что пока рано - не потерялось ли? Просто потребность есть, еще раз предлагать как-то неудобно. Не планируется ли сделать что-нибудь типа голосования по фичам? Например, как это сделано в dropbox'е, список фич, сколько голосов, в режиме ожидания/реализации/готово.

Списка планируемых фич сейчас как такового нет, работа происходит так:
1) Выпускаем очередную 4.0.x
2) Приходят багрепорты или запросы о фичах
3) Мы исправляем что можно
4) Выпускаем очередную 4.0.x
5) Goto 1

Т.е. практически все что приходит мы либо исправляем сразу, либо откладываем до 4.5 или 5.0 (например, если фича требует изменения базы).

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

Вспоминается случай с JRA-1330: http://jira.atlassian.com/browse/JRA-1330 Это была самая популярная задача в JIRA, а когда они ее закрыли с won't fix - их очень сильно критиковали и называли нехорошими словами. Хотя никаких обещаний это сделать со стороны Atlassian не было, многие пользователи, как оказалось, считали что это обязательно будет и won't fix был для них большой неожиданностью.

Сейчас у них из TOP-50 примерно половина задач не имеет никаких перспектив решения по объективным причинам, что бы я стал делать на их месте - не знаю. Оставить висеть ? Сейчас эти задачи собирают жалобы вроде "уже 5 лет висит, до сих пор не сделали". Закрыть ? Возможна крайне негативная реакция со стороны пользователей.

В общем мне идея долговременной голосовалки не нравится.

[a-b-c]

Тогда прошу занести данную фичу в список потенциальных фич, чтоб внести, когда будет такая возможность.
Кстати, можно ли посмотреть на список планируемых к реализации фич? А то по некоторым мы здесь уже общались, пришли к выводу, что пока рано - не потерялось ли? Просто потребность есть, еще раз предлагать как-то неудобно. Не планируется ли сделать что-нибудь типа голосования по фичам? Например, как это сделано в dropbox'е, список фич, сколько голосов, в режиме ожидания/реализации/готово.

Списка планируемых фич сейчас как такового нет, работа происходит так:
1) Выпускаем очередную 4.0.x
2) Приходят багрепорты или запросы о фичах
3) Мы исправляем что можно
4) Выпускаем очередную 4.0.x
5) Goto 1

Т.е. практически все что приходит мы либо исправляем сразу, либо откладываем до 4.5 или 5.0 (например, если фича требует изменения базы).

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

Вспоминается случай с JRA-1330: http://jira.atlassian.com/browse/JRA-1330 Это была самая популярная задача в JIRA, а когда они ее закрыли с won't fix - их очень сильно критиковали и называли нехорошими словами. Хотя никаких обещаний это сделать со стороны Atlassian не было, многие пользователи, как оказалось, считали что это обязательно будет и won't fix был для них большой неожиданностью.

Сейчас у них из TOP-50 примерно половина задач не имеет никаких перспектив решения по объективным причинам, что бы я стал делать на их месте - не знаю. Оставить висеть ? Сейчас эти задачи собирают жалобы вроде "уже 5 лет висит, до сих пор не сделали". Закрыть ? Возможна крайне негативная реакция со стороны пользователей.

В общем мне идея долговременной голосовалки не нравится.

Максим, спасибо за столь подробный ответ.

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

Без такого инструмента сложно представить, что будет с TS в течение года.

[admin]

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

Теоретически да, а практически - вот:
http://jira.atlassian.com/browse/JRA-3821

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

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

Без такого инструмента сложно представить, что будет с TS в течение года.

Я и сам сейчас не знаю. В ближайшее время планируем заниматься багами и мелкими улучшения, потом сайтом, потом будем думать над "большой идеей" для следующей версии. Для 4.0 "большой идеей" было упрощение интерфейса, по поводу следующей версии пока ничего не могу сказать - еще не думали на эту тему. Один из вариантов - замена RDBMS на какой-нибудь NoSQL движок (Neo4j?)