Мысли в слух по сериализации в YAML

Когда мы говорим, что существующий механизм сериализации объектов в XML файлы дает на выходе результат слишком громоздкий, чтобы удобно работать с ним в рамках CVS, то имеем ввиду не обилие разметки, а постоянное дублирование служебной информации и зависимых объектов. Можно взять сто контактов и сохранить их в сто отдельных файлов, и в каждом мы найдем: а) подробную структуру бизнес-класса, перечисление всех его полей с типами; б) все объекты, на которые наш контакт содержит ссылки (например папку, куда он входит и т.п.).

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

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

Кроме ссылок, модуль должен содержать минимальный номер структуры базы данных.

Порядок загрузки должен рассчитываться на основе анализа содержимого файлов. В будущем, когда в Firebird реализуют deferred foreign keys, порядок загрузки можно будет вообще не соблюдать.

Какое же Великое Княжество без Гедымина?

ОАО «Калинковичский мясокомбинат» начинает продвижение своего нового товарного знака «Великое княжество» для деликатесной группы продукции.

Как сообщили Продукт.ВY на предприятии, это широкий ассортимент ароматных копченостей и разнообразных колбас, а также пельменей и консервов. Продукция покоряет и завоевывает любовь и признание покупателей с первого кусочка. Поэтому и слоган «Покоряя вкусом», подчеркивающий достоинства мясных деликатесов, несет смысл «покорять» не властью и силой, а добрым и хорошим качеством продуктов.

Надо срочно исправлять ситуацию!

Все, что нажито непосильным трудом

На прикладные решения мы затратили в разы больше времени и средств, чем на платформу. Код настроек лежит в непрозрачных двоичных .gsf файлах. Проследить, вычленить, откатить изменения от версии к версии невозможно. Методика апгрейда существующих баз, переноса изменений от одного клиента другому, доработки и разработки хаотична и трудоемка. Юнит тестирование отсутствует как таковое.

Пришло время разгрести эти авгиевы конюшни.

Надо:

• Легковесный текстовый формат с минимумом разметки. Из стандартов -- YAML 1.1 вне конкуренции. Отчеты FR4 включать в файл как отформатированный, удобочитаемый XML с отступами.
• Никаких промежуточных состояний типа "настройка загружена в базу, но не активирована".
• Никаких "затягиваний" объектов по зависимостям при формировании настройки. Только то, что программист включил непосредственно, должно идти в файл.
• Один объект должен входить только в один файл. Использование одного объекта в разных прикладных системах через выделение его в отдельный модуль.
• Никакой самотужной терминологии. Хватит с нас пакетов и настроек. Даешь модули, приложения, компоненты, пространства имен и т.п.
• Сравнение и синхронизация текущего состояние базы с содержимым файлов на диске. Отдельный механизм загрузки/выгрузки не основанный на существующем коде сохранения в поток.
• Использование РУИД-ов и уникальных наименование объектов для обозначения связей. Раскрытие полного пути при сохранении элемента древовидной иерархии.
• Git или Subversion в качестве основной системы хранения и распространения настроек. Никаких больше "я переслал тебе настройку в имэйле, не забудь загрузить и активировать ее". Ветви в хранилище исходного кода для специфических решений, сделанных под конкретного клиента.
• Минимум служебной информации. Контроль версий, история и логирование средствами VCS.
• Списки обработчиков события и перекрытых методов для безболезненного совмещения нескольких прикладных решений на одной базе.

Источник картинки: http://www.marvunapp.com/Appendix3/augeanstables.htm

Firebird 2.5.2

Вышел официальный релиз Firebird 2.5.2. Мелкие улучшения и пару десятков исправленных ошибок. Всем клиентам рекомендуется обновиться.

On-line учебник по подсистеме Отдел Кадров и Расчет Заработной платы

Налетай! На сайте ГИВЦ Минсельхозпрода доступна он-лайн версия справочного пособия по подсистеме Отдел Кадров и Расчет Заработной платы.

НИВА переходит на Firebird 2.5

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

С 1-го января 2013 г. Наконец-то! Не прошло и 10 лет ;-)

2.5.17

В красный день календаря вышла версия 2.5.17. Перед большими изменениями скидываем изменения по-меньше.

Ручное изменение поля типа ссылка

Поменять поле типа ссылка, чтобы оно вместо одной таблицы ссылалось на другую, средствами Гедымина процесс длительный и непростой. Надо создать временное поле. Скопировать в него данные. Удалить исходное поле. Удалить домен. Создать новый домен. Создать новое поле. Перегнать в него исходные данные. Если к тому же поле участвует в триггере или процедуре, то придется предварительно перекомпилировать их с закоментированным текстом и восстановить в исходное состояние, после создания нового поля.

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

Предположим, в некоторой таблице TABLE_A находится поле USR$FIELD_A типа USR$DFIELD_A, которое ссылается на таблицу TABLE_B. Изменим его так, чтобы оно ссылалось на таблицу TABLE_C. Поле USR$NAME из TABLE_C используется для отображения наименований объектов в выпадающих списках.

1. Идем Исследователь-Сервис-Атрибуты-Таблицы. Находим в списке нашу таблицу и открываем в диалоговом окне. Переходим на вкладку Скрипт.
2. Ищем строку вида:

   ALTER TABLE TABLE_A ADD CONSTRAINT USR$FKTABLE_ANN FOREIGN KEY (USR$FIELD_A) REFERENCES TABLE_B (ID) ON UPDATE CASCADE;

3. Из найденой строки узнаем имя ограничения. В нашем случае это USR$FKTABLE_ANN, где вместо NN будут какие-нибудь цифры.
4. Идем в окно SQL редактора и выполняем команду:

   ALTER TABLE TABLE_A DROP CONSTRAINT USR$FKTABLE_ANN

5. Там же набираем и выполняем команду:

   ALTER TABLE TABLE_A ADD CONSTRAINT USR$FKTABLE_ANN FOREIGN KEY (USR$FIELD_A) REFERENCES TABLE_C (ID) ON UPDATE CASCADE ON DELETE CASCADE

   Обратите внимание, что правила ON UPDATE и ON DELETE вы должны указать в соответствии с логикой вашей задачи.

6. Как вы поняли, первая команда удалила старую ссылку, а вторая создала новую. Остается сообщить об изменившейся ссылке Гедымину. Для начала следует в разделе Исследователь-Сервис-Атрибуты-Таблицы узнать идентификаторы таблицы TABLE_C и ее поля USR$NAME.

   Узнать ИД проще простого: выделяем запись в гриде, правая кнопка мыши, команда Свойства...

7. Не выходя из формы просмотра с таблицами ищем TABLE_A и в ней поле USR$FIELD_A. Затем, правая кнопка мыши, комадна Свойства..., вкладка Данные:
   1. DELETERULE -- прописываем правило для удаления записи, которое мы указали в команде создания FOREIGN KEY. Например, CASCADE, RESTRICT и т.д.
8. Идем Исследователь-Сервис-Атрибуты-Домены и находим тип USR$DFIELD_A. Правая кнопка мыши, комадна Свойства..., вкладка Данные:
   1. REFTABLE -- Прописываем имя TABLE_C.
   2. REFLISTFIELD -- Имя поля из таблицы TABLE_C, которое будет использоваться для отображения в выпадающих списках.
   3. REFTABLEKEY -- ИД таблицы TABLE_C. Его мы определили выше.
   4. REFLISTFIELDKEY -- ИД поля из таблицы TABLE_C, которое будет использоваться для отображения в выпадающих списка.
   5. REFLNAME -- локализованное наименование таблицы справочника.
   6. REFLISTLNAME -- локализованное наименование поля для отображения в выпадающих списках.
   Нажимаем Ок для сохранения изменений.

В данном примере мы предполагаем, что тип USR$DFIELD_A используется единственный раз только для нашего поля USR$FIELD_A. В противном случае, следует создать новый тип, настроить его и вручную перевести на него ссылку, отредактировав запись для поля USR$FIELD_A в таблице AT_RELATION_FIELDS.