Гидра на CodePlex

Насколько мне известно SQL Lite не умеет одновременно из нескольких процессов писать в базу данных(если гидре это необходимо). Хотя могу ошибаться. По мне так лучше postgresql. Но это сугубо мое личное мнение))

SQL Lite не требует установки вообще. Это просто файл. И нет, конечно же не требуется, так как параллельно несколько Гидр работать не может, будут конфликты на логическом уровне. Которые, кстати, могут быть успешно устранены за счет SQL Lite.

Добавил 6-ой такс.

Желающие в итоге есть?

Есть желающие. Студии 2010 Express хватит? Логин на кодеплексе совпадает с форумным.

А что значит добавил 6-й таск? где его можно наблюдать?

Я так полагаю в первом посте :

да, таск, от анлийского task - задача.

Добавил в список девелоперов на codeplex

Первоначально описался. Не переделал, а переделав. Тоесть, это еще нужно сделать в рамках таска.

По SQLite есть желающие помочь? Можно сделать совместно. В первую очередь нужна Hydra.db3 (со всеми таблицами и констрейтами, что есть у текущей взрослой Гидры).

Не имею за плечами два мешка опыта, но готов попробовать с sqlite. Ткните только мне плиз пальцем поближе к тому месту откуда начать, а то с гидрой совсем дела не имел из-за MSSQL))

Sqlite .Net

Эт да) а что мы с ним делаем то... переводим полную структуру базы Гидры?

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

Вообще все сообщения должны поступать в лог? И еще вопрос, окна наследовать от этого интерфейса? Они будут поставщиками сообщений?

Все что пишется сейчас в файл неплохо бы писать в MonitorWindow. Про наследования окон не понял. Окна разве транслируют какую-то отладочную информацию?

То есть выводить в лог только exceptions, которые приходят сюда:

или вот такие вещи тоже должны туда попадать:

Да, только это... Возможно, еще то, что в MainWindow (в конструкторе, где try catch сделан) и App.xaml.cs

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

Как эти shelves использовать? Тоже думал над этим моментом поэтому попытался сделать чтобы логи работали. Единственный момент, видимо опять же нужно сохранение логов в файлы.

shelve - полка. изменения кладутся просто в репозиторий на полку, при этом не портится основной бранч. оттуда их можно достать - unshelve.
гугл по запроса.
Shelve pending changes - есть в выпадающем меню.
Unshelve - тоже (File->Source control->unshelve)

Вводите комментарий, выбираете файлы, кладёте.
Когда надо - достаёте, продолжаете изменения.

Шелв описал уже Александр, а про логи в файл - это естественно. Идея LogManager в том, что он умеет ретранслировать сообщения от своих источников LogManager.Sources (в данном случае, это все Гидра источники, главная форма, Worker) в свои слушатели. Вот случателями я предлагаю сделать FileLogListener и GuiLogListener. Последний вы как раз и успели создать в коде. Только зачем-то его создание перенесли в момент, когда нажимается кнопка Логи. А нужно в конструкторе. Потому что MonitorWindow будет получать логи начиная с того момента, как он был передан в GuiLogListener.

Понял, значит LogManager только транслятор сообщений. Смущает немного INotifyCollection или как оно на память точно не помню. Это было сделано для построения иерархии сообщений? Точнее вывода в иерархию? А есть ли коллекции реализующие данный интерфейс? Хотя наверно это все в документации есть. Хотя с другой стороны можно реализовать и без коллекции как таковой, динамически возвращать элементы по там же будет Worker и источники только, в смысле свою коллекцию сделать, тем более что из MainWindow надо эти вещи убрать в класс менеджер наверно, они ИМХО слабо с самой формой связаны. Из-за этого и пришлось вложенный класс логов сделать, дабы свойство Parent не перекрывалось.

Не совсем понял причину вложенного класса. Иерархия вложенности источников достигается за счет реализации интерфейса ILogSource, а не структуры кода.

Чтобы MainWindow наследующийся от FrameworkElement не перекрывал Parent объявленный как раз во FrameworkElement.

http://altyn.livejournal.com/340068.html