RnQHistoryToDB - хранение истории в базе данных

Sleuthhound писал(а):

База может быть одна, более того, можно писать историю с разных UIN'ов в одну таблицу, то есть под одним логином. А можно писать в разные таблицы. Это решать уже Вам.

Например:
таблица uin_test1 соответственно логин на базу test1
таблица uin_test2 соответственно логин на базу test2
в плагине идет связка хвоста имени таблицы после '_' и указанного логина на базу

Ага, поковырялся, въехал)

Скачайте последнюю версию плагина RnQHistoryToDB v2.0 Beta 2
www.im-history.ru/get.php?file=RnQHistoryToDBv20-Beta2

Там как раз такой принцип как вы описали: плагин занимается только складыванием сообщений в файл HistoryToDBMes.sql, а из файла HistoryToDBMes.sql в базу все складывает отдельная программа, висящая в трее, для просмотра истории тоже отдельная программа.

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

Насчет исчезновения не знаю почему это происходит, а вот работать под сборку x86-64 любые плагины не будут, нужны плагины собранные именно под x64. Об этом писал RapidD в соответствующем топике.

хм, точно.. вылетело из головы %)

Вышла новая версии плагина RnQHistoryToDB v2.0 Beta 3

Что нового в версии 2.0 Beta 3 от 23.10.2011:
+ RnQHistoryToDB: Добавлено контекстное меню при нажатии кнопки плагина в окне чата правой клавишей мыши.
* Общее: Оптимизация и чистка кода.
* Общее: Исправления в переводе.
* Общее: Обновлены библиотеки по работе с БД MySQL и PostgreSQL.
* Общее: Изменено размещение библиотек, необходимых для работы с базами данных.

Скачать можно здесь:
www.im-history.ru/get.php?file=RnQHistoryToDBv20-Beta3

P.S. Все заморочки с библиотеками устранены, в readme.txt описано что и куда кидать.

LSD25 писал(а):

Скачайте последнюю версию плагина RnQHistoryToDB v2.0 Beta 2
www.im-history.ru/get.php?file=RnQHistoryToDBv20-Beta2

Там как раз такой принцип как вы описали: плагин занимается только складыванием сообщений в файл HistoryToDBMes.sql, а из файла HistoryToDBMes.sql в базу все складывает отдельная программа, висящая в трее, для просмотра истории тоже отдельная программа.

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

Какие настройки синхронизации стоят (Авто, Ручная, По рассписанию - Интервалы)? Какая база? mysql, pgsql?

Авто. mysql 5.1.

LSD25 писал(а):

Авто. mysql 5.1.

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

попробовал еще раз. сервак включен, все замечательно.
вырубаю. отправляю сообщение - крыска подвисает секунд на 10 и сообщение уходит на другой номер.
мелочь, но немного не приятно ожидание) может имеет смысл сделать проверку доступности БД? еси ответа нет сразу, то откладывать действие. ну т.е. БД должна ответить сразу, в течении, например, 500 мс, если нет, недоступна значит.
чтобы сократить задержку как-то.
ясное дело, что такие случаи редки. но мало ли, вдруг БД не доступна))

UPD(26.10.12): Кстати, было бы неплохо иметь возможность указывать так называемое зеркало БД. Т.е. запускаю крысу, плагин проверяет доступен ли адресс и если нет, использует второй. Почему возникла мысль - сервер БД поднял на домашнем компе. Чтобы внутри сети домашней коннектить к БД, указываю локальный адрес (чтобы указать внешний белый статический, нада ковыряться в маршрутизации, что не очень хотелось бы, пака что), а прихожу на работу, включаю, и естесн локалки уже нету той, надо по внешнему коннектить. Не хотелось бы разносить конфиг на разные клиенты пака что.

LSD25 писал(а):

попробовал еще раз. сервак включен, все замечательно.
вырубаю. отправляю сообщение - крыска подвисает секунд на 10 и сообщение уходит на другой номер.
мелочь, но немного не приятно ожидание) может имеет смысл сделать проверку доступности БД? еси ответа нет сразу, то откладывать действие. ну т.е. БД должна ответить сразу, в течении, например, 500 мс, если нет, недоступна значит.
чтобы сократить задержку как-то.
ясное дело, что такие случаи редки. но мало ли, вдруг БД не доступна))

Промоделирую такую ситуацию, но вообще не должно такого быть.

LSD25 писал(а):

UPD(26.10.12): Кстати, было бы неплохо иметь возможность указывать так называемое зеркало БД. Т.е. запускаю крысу, плагин проверяет доступен ли адресс и если нет, использует второй. Почему возникла мысль - сервер БД поднял на домашнем компе. Чтобы внутри сети домашней коннектить к БД, указываю локальный адрес (чтобы указать внешний белый статический, нада ковыряться в маршрутизации, что не очень хотелось бы, пака что), а прихожу на работу, включаю, и естесн локалки уже нету той, надо по внешнему коннектить. Не хотелось бы разносить конфиг на разные клиенты пака что.

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

Sleuthhound писал(а):

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

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

LSD25 писал(а):

вообще, под зеркалом я имею ввиду другое.. таже БД, с тем же логином и пасом, но под другим IP. логин и пасс теже, в итоге.

Подумаю над этим, как проще реализовать.

Вышла новая версии плагина RnQHistoryToDB v2.0 RC1

Что нового в версии 2.0 RC1 от 11.11.2011:
* Общее: Оптимизация и чистка кода.
* Общее: Все программы подписываются моим сертификатом (Mikhail Grigoryev - Open Source Developer).
* Общее: Обновлена библиотека по работе с БД SQLite до версии 3.7.9
* RnQHistoryToDB: Диалог настроек перенесен в программу HistoryToDBViewer.
* HistoryToDBViewer: Добавлен диалог справки с параметрами запуска программы.
* HistoryToDBViewer: Добавлен импорт истории из QIP 2005 (плагины myHistory и sHistory).
* HistoryToDBSynс: Процедура добавления сообщений в БД теперь запускается в отдельном потоке.
* HistoryToDBSynс: Добавлен диалог справки с параметрами запуска программы.
* HistoryToDBSynс: Добавлены счетчики добавленных, забракованных сообщений и оставшегося времени.

Скачать можно здесь:
www.im-history.ru/get.php?file=RnQHistoryToDBv20-RC1

В RC1 была найдена небольшая ошибка, сегодня все поправил и перевыложил архив.

Качаем:
www.im-history.ru/get.php?file=RnQHistoryToDBv20-RC1

А зачем это всё? В чем преимущества?

Profi писал(а):

А зачем это всё? В чем преимущества?

А может стоит прочитать первый пост? Там вроде все по-русски, зачем это и что с ним делать.

В чем преимущества, Вы спрашиваете? Преимущества перед чем? Сформулируйте вопрос более полно.

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

LubitelSofta писал(а):

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

Плагин как раз и делает единое хранилище истории для разных im-клиентов. Некий аналог "единый центр истории как в квип", только тут под разные im-клиенты, с открытым кодом и БД может быть ваша и расположена где угодно. И эту БД контролируете Вы, а не какой-то дядя, который может читать ваши сообщения.

Все преимущества на лицо:

1. Единая база истории для разных IM-клиентов. Плагин пока есть для QIP и RnQ, в планах Miranda и qutIM и т.д.
2. Открытый код плагинов и утилит => Гарантия того, что за вашей историей никто не следит и никто её параллельно никуда не копирует.
3. Вы сами контролируете свою единую базу => Гарантия того, что за вашу историю никто кроме Вас не читает.

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

Утилита позволяет создать БД, создать/удалить пользователя, создать/удалить структуру таблиц, выдать/забрать права пользователю на эти таблицы.

Работа утилиты протестирована на последних версиях БД MySQL, SQLite, PostgreSQL, Firebird





Скачать можно здесь:
www.im-history.ru/get.php?file=HistoryToDBCreateDB

Исходники будут выложены на googlecode в ближайшее время.

вот это удобно однако хотя меня и phpmyadmin устраивает тоже) да хоть терминал)

Вышла новая версии плагина RnQHistoryToDB v2.0 RC2

Что нового в версии 2.0 RC2 от 22.11.2011:
* Общее: Оптимизация и чистка кода.
* Общее: Добавлена поддержка БД Firebird.
+ RnQHistoryToDB: Добавлена возможность использования файла конфигурации, создаваемого утилитой HistoryToDBCreateDB (DefaultUser.ini), который при запуске RnQ копируется в профиль пользователя.
* HistoryToDBViewer: Исправлена проблема при удалении истории в БД SQLite.
+ HistoryToDBViewer: Добавлено сохранение позиций окна программы.
* HistoryToDBViewer: Изменены несколько иконок im-клиентов (Спасибо HDHmetro).
* HistoryToDBViewer: Исправлено место появления основного окна в двухмониторной конфигурации.
* HistoryToDBViewer: В окне импорта истории изменены прогрессбары на более современные.
+ HistoryToDBSynс: Добавлено сохранение позиций окна программы.

Скачать можно здесь:
www.im-history.ru/get.php?file=RnQHistoryToDBv20-RC2

Выкладываю RnQHistoryToDB v2.0 RC3

Из изменений:

v2.0 RC3 от 25.11.2011:
+ HistoryToDBViewer: Добавлен прогресбар на ожидание разворачивания списка контактов и загрузки
большого объема истории для просмотра ( forum.qip.ru/showpost.php?p=393914&postcount=124 )
+ HistoryToDBViewer: В импорте истории появилась возможность менять Никнейм и UserID.
* HistoryToDBViewer: Изменен формат вывода истории.
* HistoryToDBViewer: При просмотре истории из БД Firebird исправлена проблема с переносом строк.
* HistoryToDBViewer: Исправлена проблема с ошибочным создание файла HistoryToDBForms.ini в папке IM-клиента.
* HistoryToDBSynс: Исправлена проблема с ошибочным создание файла HistoryToDBForms.ini в папке IM-клиента.
* RnQHistoryToDB: Доработана процедура копирования файла DefaultUser.ini
* RnQHistoryToDB: Произведена унификация файла HistoryToDB.sql. Теперь данные из него можно добавлять
в любую БД (MySQL, PostgreSQL, SQLite, Firebird) без исправления insert запросов. Для корректной работы с БД
PostgreSQL или Firebird необходимо пересоздать БД с использованием новой версии (v1.2) утилиты HistoryToDBCreateDB
или обновить структуру существующей БД. Для обновления структуры БД выполните скрипт:
для БД PostgreSQL - SQL\update\postgresql-update-uni.sql
для БД Firebird - SQL\update\firebird-update-uni.sql

Качаем
www.im-history.ru/get.php?file=RnQHistoryToDBv20-RC3

Выкладываю RnQHistoryToDB v2.0 RC4

Из изменений:

v2.0 RC4 от 28.11.2011:
* HistoryToDBViewer: Исправлена проблема с появлением файла HistoryToDB.ini в корне диска.
* HistoryToDBViewer: Доработан формат импорта истории из sHistory (Возможный формат даты ЧЧ:ММ:СС DD/MM/YYYY или ЧЧ:ММ:СС DD.MM.YYYY).
* HistoryToDBViewer: Исправлена ошибка с символами ( ) при импорте истории из формат sHistory.
* HistoryToDBViewer: Исправлено место появления окна настроек в двухмониторной конфигурации.
* HistoryToDBViewer: При просмотре истории из БД SQLite исправлена проблема с переносом строк.
* HistoryToDBViewer: Изменен формат вывода истории чатов.

Качаем
www.im-history.ru/get.php?file=RnQHistoryToDBv20-RC4