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

AL> Очевидно, что на разных нодах может быть разный порядок сообщений в эхах или даже разное содержимое. В связи с чем, я пока придумал только держать отдельную базу сообщений для каждой из нод.
В Qt-клиенте для всех нод одна и та же база. Алгоритм работы примерно таков:
1. Фетчим одну и ту же эху с нескольких нод в одно и то же место
2. Если отправляем туда сообщение, то оно уходит на первую ноду из списка

Каждый из вариантов имеет свои плюсы. Я не стал городить раздельные базы, потому что юзер-НЕфрендли. А произвольную отправку не стал делать, потому что лень =)

AL>> Очевидно, что на разных нодах может быть разный порядок сообщений в эхах или даже разное содержимое. В связи с чем, я пока придумал только держать отдельную базу сообщений для каждой из нод.
vit01> В Qt-клиенте для всех нод одна и та же база. Алгоритм работы примерно таков:
vit01> 1. Фетчим одну и ту же эху с нескольких нод в одно и то же место

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

vit01> 2. Если отправляем туда сообщение, то оно уходит на первую ноду из списка

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

vit01> Я не стал городить раздельные базы, потому что юзер-НЕфрендли.

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

зы Вопрос пока что чисто теоретический.

AL>> Пока у меня одна база, так как нет смысла, но когда у нас будет возможность получить разный набор сообщений с разных нод, это может стать проблемой.
vit01> И где здесь проблема? Предположим, есть эха news.15. На станции 1 туда, к примеру, постят новости с Лора, а на станции 2 - с опеннета. Юзер фетчит их в одну базу. В итоге получает _одну_ ленту с новостями обоих сайтов. Так даже читать приятнее.

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

AL>>> Пока у меня одна база, так как нет смысла, но когда у нас будет возможность получить разный набор сообщений с разных нод, это может стать проблемой.
vit01>> И где здесь проблема? Предположим, есть эха news.15. На станции 1 туда, к примеру, постят новости с Лора, а на станции 2 - с опеннета. Юзер фетчит их в одну базу. В итоге получает _одну_ ленту с новостями обоих сайтов. Так даже читать приятнее.
AL> А когда в эту эху с ноды 1 приходят новости с опеннета, а со второй -- с хабры, и с обоих нод репостится ЛОР, то есть вероятность, что поинт будет получать не все сообщения. Причём весьма высокая. Просто потому, что тогда совсем разный порядок сообщений может оказаться. Я понимаю, что это будет не так удобно для пользователя, но зато позволит не изобретать извращённых алгоритмов для разруливания этой путаницы.

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

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

Ну а так они и без одноимённых эх могут теряться, тут разницы нет большой.

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

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

vit01> Ну а так они и без одноимённых эх могут теряться, тут разницы нет большой.

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

> И если создать разные базы для разных нод, то потерь не будет.

Требую наглядного примера (запрос => результат => файл в общей базе)