Здравствуйте, SchweinDeBurg.
Вы писали:
SDB> Здравствуйте, xBlackCat, Вы писали: SDB> BC>Обращаюсь к людям, скачавших/пользующихся Rojac. SDB> А в каком формате хранится БД и можно ли подключить/сконвертировать уже существующий .mdb-файл от Януса? Вику бегло просмотрел, но этой информации не нашел.
К сожалению, нельзя сделать импорт из Януса (спасибо за мысль подкинутую )
Сейчас существует два "движка" хранения: встраиваемая база H2SQL и внешняя MySQL. При запуске программы можно выбрать параметры. Потенциально можно использовать любую SQL БД, для которой есть JDBC драйвер (кстати, ищу знатоков для портирования на MSSQL и PostgreSQL. Сам не успеваю таким занятся).
Между базами Rojac можно делать импорт данных.
1. Сильно не хватает возможности подстроить шрифты (а в идеале — css-стили), которыми отображаются сообщения. В браузере это обычно первое, что я настраиваю "под себя", так что здесь всё выглядит уж очень непривычно — текст цитаты мельче привычного, основной наоборот слишком крупный... Придирки, конечно, но если бы была такая настройка — было бы очень неплохо имхо
2. Удивило, что при нескольких выделенных форумах в Navigation, если сделать mark all messages as read — как прочтенный помечается только форум с фокусом, а не все выделенные. Имхо это нелогично — если из 10 форумов, на которые я подписан, мне сейчас интересны только два — было бы удобно прочитать только их, а остальные все кучей пометить как as read. Сейчас придется помечать по одному, либо оставлять непрочтенными, даже если в них нет ни одной интересной темы.
3. Собственно о темах. Как узнать, в каких темах есть непрочитанные сообщения? Интуитивно я подозревал, что такие темы должны "всплывать" наверх и/или подсвечиваться жирным — как, например, это происходит при чтении NNTP-тредов в Thunderbirs'е или как работает дерево в online-версии rsdn. Здесь же визуально я не нашел ни одного отличия между прочитанными и непрочитанными топиками (плохо искал?), и единственный способ узнать, что в форуме нового — это протыкаться по кнопкам "next/prev unread".
4. Сообщение о загрузке имхо неплохо было бы скрывать после того, как загрузка будет завершена — полезной информации в нем имхо минимум, а каждый раз тыкать кнопку "закрыть" — слегка задалбывает. А может быть и вообще не стоит открывать это окошко — ограничиться прогрессом загрузки где-нибудь на статусбаре/тулбаре, кликнув по которому можно узнать подробную информацию. Если, конечно, скачивание и заполнение базы не требует монопольного доступа.
Здравствуйте, Пацак.
Вы писали:
П> Hello, xBlackCat. П> Что подумалось за один вечер использования: П> 1. Сильно не хватает возможности подстроить шрифты (а в идеале — css-стили), которыми отображаются сообщения. В браузере это обычно первое, что я настраиваю "под себя", так что здесь всё выглядит уж очень непривычно — текст цитаты мельче привычного, основной наоборот слишком крупный... Придирки, конечно, но если бы была такая настройка — было бы очень неплохо имхо
Эта возможность уже запланированна: как будет реализован нормальный редактор/рендерер сообщений, эти настройки пойдут в жизнь.
(и Ctrl+Z тогда же будет реализована )
П> 2. Удивило, что при нескольких выделенных форумах в Navigation, если сделать mark all messages as read — как прочтенный помечается только форум с фокусом, а не все выделенные. Имхо это нелогично — если из 10 форумов, на которые я подписан, мне сейчас интересны только два — было бы удобно прочитать только их, а остальные все кучей пометить как as read. Сейчас придется помечать по одному, либо оставлять непрочтенными, даже если в них нет ни одной интересной темы.
Забыл поставить правило для выделения: только одна нода. Исправлю.
Неинтересные темы можно игнорировать. Тогда они не будут появляться даже в панели "Последние дискуссии".
П> 3. Собственно о темах. Как узнать, в каких темах есть непрочитанные сообщения? Интуитивно я подозревал, что такие темы должны "всплывать" наверх и/или подсвечиваться жирным — как, например, это происходит при чтении NNTP-тредов в Thunderbirs'е или как работает дерево в online-версии rsdn. Здесь же визуально я не нашел ни одного отличия между прочитанными и непрочитанными топиками (плохо искал?), и единственный способ узнать, что в форуме нового — это протыкаться по кнопкам "next/prev unread".
Хмм.. Какие настройки в системе? Какой L&F используется?
Сейчас все иконки сообщений имеют три состояния:
— непрочитанное сообщение. Также выделено жирным шрифтом
— прочитанное сообщение
— в подветке есть непрочитанные сообщения.
П> 4. Сообщение о загрузке имхо неплохо было бы скрывать после того, как загрузка будет завершена — полезной информации в нем имхо минимум, а каждый раз тыкать кнопку "закрыть" — слегка задалбывает. А может быть и вообще не стоит открывать это окошко — ограничиться прогрессом загрузки где-нибудь на статусбаре/тулбаре, кликнув по которому можно узнать подробную информацию. Если, конечно, скачивание и заполнение базы не требует монопольного доступа.
Это отключается в настройках: сними выделенные галочки, как на скриншоте http://clip2net.com/s/1kDbw
П> А так вообще очень неплохо имхо, спасибо! П> PS Запускал под Linux Mint, если это важно
Спасибо за отзыв
Здравствуйте, xBlackCat, Вы писали:
BC>Здравствуйте, SchweinDeBurg. BC>Вы писали:
SDB>> Здравствуйте, xBlackCat, Вы писали: SDB>> BC>К сожалению, нельзя сделать импорт из Януса (спасибо за мысль подкинутую ) SDB>> Не за что, если это реализовать, то было бы здорово — 2 гига информации терять не хочется, а на MSSQL я что-то не созрел пока. SDB>> BC>Сейчас существует два "движка" хранения: встраиваемая база H2SQL и внешняя MySQL. SDB>> Насколько я понимаю, "ручной" импорт в MySQL не должен быть совсем уж непосильной задачей, если, конечно, структура БД не слишком отличается. За Джаву не скажу, а вот ODBC я в свое время использовал довольно плотно (правда не знаю, есть ли провайдер для MySQL).
BC>Для ручного импорта нужно знать структуру БД. Думаю покопаться во внутренностях Janus'а на досуге на счёт базы. Если у кого есть уже готовый DDL для создания БД в Янусе — буду рад принять в дар
Скрипт есть в ресурсах и он вроде распаковывается автоматом. Лави
Здравствуйте, xBlackCat, Вы писали:
BC>Обращаюсь к людям, скачавших/пользующихся Rojac.
А в каком формате хранится БД и можно ли подключить/сконвертировать уже существующий .mdb-файл от Януса? Вику бегло просмотрел, но этой информации не нашел.
Здравствуйте, xBlackCat, Вы писали:
BC>К сожалению, нельзя сделать импорт из Януса (спасибо за мысль подкинутую )
Не за что, если это реализовать, то было бы здорово — 2 гига информации терять не хочется, а на MSSQL я что-то не созрел пока.
BC>Сейчас существует два "движка" хранения: встраиваемая база H2SQL и внешняя MySQL.
Насколько я понимаю, "ручной" импорт в MySQL не должен быть совсем уж непосильной задачей, если, конечно, структура БД не слишком отличается. За Джаву не скажу, а вот ODBC я в свое время использовал довольно плотно (правда не знаю, есть ли провайдер для MySQL).
Здравствуйте, SchweinDeBurg.
Вы писали:
SDB> Здравствуйте, xBlackCat, Вы писали: SDB> BC>К сожалению, нельзя сделать импорт из Януса (спасибо за мысль подкинутую ) SDB> Не за что, если это реализовать, то было бы здорово — 2 гига информации терять не хочется, а на MSSQL я что-то не созрел пока. SDB> BC>Сейчас существует два "движка" хранения: встраиваемая база H2SQL и внешняя MySQL. SDB> Насколько я понимаю, "ручной" импорт в MySQL не должен быть совсем уж непосильной задачей, если, конечно, структура БД не слишком отличается. За Джаву не скажу, а вот ODBC я в свое время использовал довольно плотно (правда не знаю, есть ли провайдер для MySQL).
Для ручного импорта нужно знать структуру БД. Думаю покопаться во внутренностях Janus'а на досуге на счёт базы. Если у кого есть уже готовый DDL для создания БД в Янусе — буду рад принять в дар
На счёт импорта из mdb — тут проблемка небольшая: прямые JDBC к MS Access базам платные. Прийдётся сделать JDBC-ODBC мост. Я ещё не придумал, как это красивее сделать с точки зрения юзера.
Здравствуйте, xBlackCat, Вы писали:
BC>Для ручного импорта нужно знать структуру БД. Думаю покопаться во внутренностях Janus'а на досуге на счёт базы. Если у кого есть уже готовый DDL для создания БД в Янусе — буду рад принять в дар
Там структура БД довольно часто менялась даже в пределах одной "мажорной" версии, насколько я помню, и в состав Януса входит так называемый реструктуризатор, который эту ситуацию обрабатывает (по крайней мере — должен, у меня падал).
BC>На счёт импорта из mdb — тут проблемка небольшая: прямые JDBC к MS Access базам платные.
Здравствуйте, SchweinDeBurg.
Вы писали:
SDB> BC>На счёт импорта из mdb — тут проблемка небольшая: прямые JDBC к MS Access базам платные. SDB> Жесть, ничего не скажешь!
Здравствуйте, xBlackCat, Вы писали:
BC>Потенциально можно использовать любую SQL БД, для которой есть JDBC драйвер (кстати, ищу знатоков для портирования на MSSQL и PostgreSQL. Сам не успеваю таким занятся).
А зачем это вообще делать? Не проще ли определиться с "идеальным" встраиваемым хранилищем, и не парить себе мозг доступным зоопарком? Кому какое дело, что там шуршит под капотом FB, SQLite или MSSQL
Здравствуйте, hattab.
Вы писали:
H> Здравствуйте, xBlackCat, Вы писали: H> BC>Потенциально можно использовать любую SQL БД, для которой есть JDBC драйвер (кстати, ищу знатоков для портирования на MSSQL и PostgreSQL. Сам не успеваю таким занятся). H> А зачем это вообще делать? Не проще ли определиться с "идеальным" встраиваемым хранилищем, и не парить себе мозг доступным зоопарком? Кому какое дело, что там шуршит под капотом FB, SQLite или MSSQL
К сожалению, встраиваемые СУБД не дают приемлемого качества/скорости. Тот же H2SQL забирает на себя существенную часть кучи при работе с БД, что иногла приводит к OOM exception на установленном по-умолчаниб размере кучи в 64Мб.
Здравствуйте, xBlackCat, Вы писали:
BC> H> А зачем это вообще делать? Не проще ли определиться с "идеальным" встраиваемым хранилищем, и не парить себе мозг доступным зоопарком? Кому какое дело, что там шуршит под капотом FB, SQLite или MSSQL
BC> К сожалению, встраиваемые СУБД не дают приемлемого качества/скорости. Тот же H2SQL забирает на себя существенную часть кучи при работе с БД, что иногла приводит к OOM exception на установленном по-умолчаниб размере кучи в 64Мб.
Ну ладно, H2SQL тебя не устраивает. Почему не взять SQLite или Firebird Embedded? Обе кроссплатформенные (у тебя вроде кто-то интересовался работой под линуксом), обе шустренькие (Avalon использует SQLite, и вполне себе неплохо справляется на базе в 1.2Gb), FBE так и вообще ураган
H> Ну ладно, H2SQL тебя не устраивает. Почему не взять SQLite или Firebird Embedded? Обе кроссплатформенные (у тебя вроде кто-то интересовался работой под линуксом), обе шустренькие (Avalon использует SQLite, и вполне себе неплохо справляется на базе в 1.2Gb), FBE так и вообще ураган
SQLite был одним из первых претендентов на разработку.
Все их преимущество съедается в JNI — в результате SQLite тормозил сильнее SmallSQL (а он ещё тормоз был).
Здравствуйте, xBlackCat, Вы писали:
BC> H> Ну ладно, H2SQL тебя не устраивает. Почему не взять SQLite или Firebird Embedded? Обе кроссплатформенные (у тебя вроде кто-то интересовался работой под линуксом), обе шустренькие (Avalon использует SQLite, и вполне себе неплохо справляется на базе в 1.2Gb), FBE так и вообще ураган
BC> SQLite был одним из первых претендентов на разработку. BC> Все их преимущество съедается в JNI — в результате SQLite тормозил сильнее SmallSQL (а он ещё тормоз был).
То есть вообще ничего приличного встроенного использовать не получилось, или как? Но ведь и с внешними БД взаимодействие осуществляется через прослойку Ну а FBE вообще собирается из того же кода, что и его standalone версия, там разницу можно почувствовать, разве что на многопоточном доступе (более того, встроенной версии не требуется межпроцессное взаимодействие).
Здравствуйте, hattab, Вы писали:
H>Ну ладно, H2SQL тебя не устраивает. Почему не взять SQLite
Какие то странные проблемы с строковыми блобами и периодические тормоза на запросе тем форума. Транзакции номинальны, что приводит к проблемам при многопоточном доступе. Это я про sqlite в янусе.
H> или Firebird Embedded
Странный SQL, много проблем совместимости, посредственный перформанс.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, hattab.
Вы писали:
H> То есть вообще ничего приличного встроенного использовать не получилось, или как? Но ведь и с внешними БД взаимодействие осуществляется через прослойку Ну а FBE вообще собирается из того же кода, что и его standalone версия, там разницу можно почувствовать, разве что на многопоточном доступе (более того, встроенной версии не требуется межпроцессное взаимодействие).
С внешними БД работа идёт через сокеты.
SQLite силён обновлениями в транзакциях: открыл коннекшн, начал транзакцию, сделал 1000х запросов, закоммитил. Тогда он быстрый. А в моём случае не получается держать открытый коннекшн долго — параллельность работы ломается.
К примеру, если я на Н2 в базу вставляю 1000 сообщений, то они заполняюся за 10 сек. В SQLite этот же механизм вставлял их более 15 минут (точные цифры не помню, но порядок был именно такой). А переделывать структуру приложения только ради SQLite не хотелось.
Он меня полностью устраивает Только если говоришь в форуме с 10К постами и больше "пометить все, как прочитанные", может закончится память на куче в 64Мб.
Здравствуйте, xBlackCat, Вы писали:
BC>Он меня полностью устраивает Только если говоришь в форуме с 10К постами и больше "пометить все, как прочитанные", может закончится память на куче в 64Мб.
А зачем ограничивать кучу таким смешным значением?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK.
Вы писали:
AVK> Здравствуйте, xBlackCat, Вы писали: AVK> BC>Он меня полностью устраивает Только если говоришь в форуме с 10К постами и больше "пометить все, как прочитанные", может закончится память на куче в 64Мб. AVK> А зачем ограничивать кучу таким смешным значением?
Ну хотя бы из-за того, что при такой куче JVM уже ест около 200Мб в памяти (на х64 системе). Ну и просто дополнительный стимул не тратить зря память
При внешней БД этого размера кучи более чем достаточно.
Здравствуйте, AndrewVK, Вы писали:
AVK> H> или Firebird Embedded
AVK> Странный SQL
Чего странного в SQL-92 + части SQL-99 + некоторых расширениях? До FB активно работал с MSSQL 6.5 — 2000, при переходе на FB проблем с SQL не испытал
AVK> много проблем совместимости
Любые проблемы совместимости файлов БД решаются через backup/restore. Несовместимостей между версиями сервера с 1.5 по 2.5 не обнаружено (использую тонкую оберточку над API — UIB)
AVK> посредственный перформанс
Оракулу сольет конечно, но потребности янусов перекроет многократно.
Здравствуйте, hattab, Вы писали:
H>Чего странного в SQL-92 + части SQL-99 + некоторых расширениях?
Странного то, что в некоторых местах парсер некорректно работал.
H> До FB активно работал с MSSQL 6.5 — 2000, при переходе на FB проблем с SQL не испытал
А вот в янусе проблемы были.
AVK>> посредственный перформанс
H>Оракулу сольет конечно, но потребности янусов перекроет многократно.
Увы, но все не так оптимистично. Оптимизатор в FB лажает неслабо. А на простеньких запросах да, проблем нет.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, xBlackCat, Вы писали:
BC> С внешними БД работа идёт через сокеты.
Сокеты дают меньший оверхед чем JNI?
BC> SQLite силён обновлениями в транзакциях: открыл коннекшн, начал транзакцию, сделал 1000х запросов, закоммитил. Тогда он быстрый. А в моём случае не получается держать открытый коннекшн долго — параллельность работы ломается.
С параллельностью понятно.
BC> К примеру, если я на Н2 в базу вставляю 1000 сообщений, то они заполняюся за 10 сек. В SQLite этот же механизм вставлял их более 15 минут (точные цифры не помню, но порядок был именно такой). А переделывать структуру приложения только ради SQLite не хотелось.
Здравствуйте, xBlackCat, Вы писали:
BC> Здравствуйте, hattab. BC> Вы писали:
BC> H> Ну ладно, H2SQL тебя не устраивает.
BC> Он меня полностью устраивает Только если говоришь в форуме с 10К постами и больше "пометить все, как прочитанные", может закончится память на куче в 64Мб.
Либо это устраивает и проблема гипотетическая, либо проблема реальная, а значит не устраивает
Здравствуйте, AndrewVK, Вы писали:
AVK> AVK>> посредственный перформанс
AVK> H>Оракулу сольет конечно, но потребности янусов перекроет многократно.
AVK> Увы, но все не так оптимистично. Оптимизатор в FB лажает неслабо. А на простеньких запросах да, проблем нет.
Здравствуйте, xBlackCat, Вы писали:
BC>Здравствуйте, AlexNek. BC>Вы писали:
AN>> Скрипт есть в ресурсах и он вроде распаковывается автоматом. AN>> Лави AN>> [ img ]http://www.russinger.com/img_an/janus/janus-db.png[/ img ]
BC>Спасибо большое!
Да не за что, мне просто диаграмма понадобилась гораздо раньше, но пришлось ее из "базы вытаскивать", а потом и скрипт заметил
Здравствуйте, AndrewVK.
Вы писали:
AVK> Здравствуйте, xBlackCat, Вы писали: AVK> BC>Ну хотя бы из-за того, что при такой куче JVM уже ест около 200Мб в памяти (на х64 системе). AVK> Да тоже, вобщем то, не так уж и много. AVK> BC> Ну и просто дополнительный стимул не тратить зря память AVK> Ясно, религия.
Миссия, скорее.
У каждого приложения должена быть цель. В Rojac это — минимум памяти (а то ява в свопе — это печатьно) и минимальный интерфейс с максимальной функциональностью.
AVK> BC>При внешней БД этого размера кучи более чем достаточно. AVK> А то, что память жрется процессом СУБД тебя уже не волнует?
Если MySQL уже стоит в системе, значит это кому-нибудь нужно?
Я не заставляю ставить MySQL, но если он уже есть, почему бы его не использовать?
Здравствуйте, hattab.
Вы писали:
H> Здравствуйте, xBlackCat, Вы писали: H> BC> Здравствуйте, hattab. H> BC> Вы писали: H> BC> H> Ну ладно, H2SQL тебя не устраивает. H> BC> Он меня полностью устраивает Только если говоришь в форуме с 10К постами и больше "пометить все, как прочитанные", может закончится память на куче в 64Мб. H> Либо это устраивает и проблема гипотетическая, либо проблема реальная, а значит не устраивает
Проблема не надумана, но возникает только в единичных случаях, при обновлении огромного кол-ва сообщений в базе (>10000). Решается простым увиличением кучи в настройках приложения до 128М.
Здравствуйте, AndrewVK.
Вы писали:
AVK> Здравствуйте, xBlackCat, Вы писали: AVK> BC>Если MySQL уже стоит в системе, значит это кому-нибудь нужно? AVK> Стоит — не значит жрет память. Но я понял — мусор можно просто замести под половичек.
Странное отношение. Вот у меня MySQL стоит и работает, потому что он мне нужен для работы. Почему бы это хранилище не использовать? Я же не заставляю всех ставить MySQL: по-умолчанию будет использоваться H2SQL
Здравствуйте, xBlackCat, Вы писали:
BC>Странное отношение.
Не то слово.
BC> Вот у меня MySQL стоит и работает, потому что он мне нужен для работы.
Еще раз — MySQL, если просто стоит, памяти жрет немного. А вот если ты начнешь работать с ним, потребляемая память начнет расти. Так что с внешней БД ты просто мусор под половичек заметаешь.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK.
Вы писали:
AVK> Здравствуйте, xBlackCat, Вы писали: AVK> BC>Странное отношение. AVK> Не то слово. AVK> BC> Вот у меня MySQL стоит и работает, потому что он мне нужен для работы. AVK> Еще раз — MySQL, если просто стоит, памяти жрет немного. А вот если ты начнешь работать с ним, потребляемая память начнет расти. Так что с внешней БД ты просто мусор под половичек заметаешь.
Память, которую потребит MySQL легко вернётся в систему, как только буфер не будет нужен. С явой будет всё по-другому. По-моему, вариант с MySQL будет более щадящим для памяти. Разве не так?
Здравствуйте, AndrewVK.
Вы писали:
AVK> Здравствуйте, xBlackCat, Вы писали: AVK> BC>Странное отношение. AVK> Не то слово. AVK> BC> Вот у меня MySQL стоит и работает, потому что он мне нужен для работы. AVK> Еще раз — MySQL, если просто стоит, памяти жрет немного. А вот если ты начнешь работать с ним, потребляемая память начнет расти. Так что с внешней БД ты просто мусор под половичек заметаешь.
Здравствуйте, xBlackCat, Вы писали:
BC>Память, которую потребит MySQL легко вернётся в систему, как только буфер не будет нужен. С явой будет всё по-другому.
Что, JVM забирает сразу максимальный объем памяти? Что то сомневаюсь я.
BC> По-моему, вариант с MySQL будет более щадящим для памяти.
Может быть, но несильно.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>