Астралинуксовский,

Астралинуксовский, Если еще не поздно то вставлю свои 5 копеек. Хотите Линтре - покупайте ящик транквилизаторов и седативов.
1. Документация по их честному заявлению написана по ГОСТу. Написана так что читать невозможно. Примеров для некоторых задач вообще нет. Некоторые нужно искать в других разделах. К примеру: так и не нашел как установить текущее значение сиквенса на необходимое, все что нашел только стартовое значение.
2. Просто так создать несколько баз данных нельзя. Каждая БД запускается отдельным процессом. На каждый процесс свой порт для работы в сети (наверно один из немногих плюсов). На хосте по факту ставится полноценный Линтер из которого запускается nodetab с вручную заполненной таблицей "имя бд\хост\порт". Старт каждой БД на серваке вручную или пишите скрипты и пихайте сами куда хотите.
3. Язык SQL и "тот который" используется в процедурах писали разные люди (сами разработчики рассказывали), так что не удивляйтесь если один и тот же тип данных будет восприниматься только в SQL, но не в процедурах.
4. Коль о процедурах. Каждая строка тела процедуры заканчивающаяся ";" должна так же содержать "\\", то есть в итоге получаем ";\\". Таким образом обозначается конец строки) без нее при скармливании процедуры вас ожидает обрезка тела процедуры ровно до этой ";", все после исчезнет. Хотя при создании процедур не из файлов, а на прямую в linteradmin это не требуется.
5. Забудьте про тип STRING. Онли VARCHAR(4096) и ни символом больше. Такова реализация архитектуры. Причем 4096 это суммарная длинна все полей типа (VARCHAR, CHAR, ...). Может ошибка версии СУБД, может особенности архитектуры, может мой косяк (эксперименты с этим продуктом меня за доконали) в магическое 4096 включаются и остальные типы.
6. Техподдержка действительно оперативна, за что им респект. Порой отвечают на крайне поздние запросы. Но любят потом присылать письма с предложением купить подписку. Хотя большинство обращений к ним это баги и отсутствие внятных док.

В итоге: после Линтер-ВС переход на Линтер был для меня "малость" неприятен. По большому счету - расстройство ЦНС гарантировано)) В первую очередь уж очень сильными особенностями. Если использовать как чистый SQL - нормально. Хотите процедурный язык - готовтесь к багам.

З.Ы. Количество пунктов было 14 но в процессе случайно грохнул половину. Там были в основном особенности и сюрпризы работы СУБД, в том числе бэкапы и т.п.

Ермаков Михаил,

Ермаков Михаилheleo,
Теперь по Вашим пунктам - я не буду высказывать своё мнение - просто подтверждение или комментарий.
heleo1. Документация по их честному заявлению написана по ГОСТу. Написана так что читать невозможно. Примеров для некоторых задач вообще нет. Некоторые нужно искать в других разделах. К примеру: так и не нашел как установить текущее значение сиквенса на необходимое, все что нашел только стартовое значение.

Сиквенс был выше. Остальное - отчасти я согласен - есть проблемы в связности изложения и в целостности примеров, но нужно учитывать, что это документация, а не книжка по работе в системой или с SQL.
Если есть список "тёмных мест" - пришлите пожалуйста - будем устранять или укажу, где можно найти ответы.


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

С примерами могу сказать так. Работать с BLOB не совсем ясно как. В примерах показана запись BLOB одноразовая, а если нужно записать в цикле через UPDATE дана только функция INSERT и REPLACE. С INSERT не сложилось, то ли баг, то ли что то еще. В итоге наращивание BLOB произвел через:


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

Ермаков Михаилheleo2. Просто так создать несколько баз данных нельзя. Каждая БД запускается отдельным процессом. На каждый процесс свой порт для работы в сети (наверно один из немногих плюсов). На хосте по факту ставится полноценный Линтер из которого запускается nodetab с вручную заполненной таблицей "имя бд\хост\порт". Старт каждой БД на серваке вручную или пишите скрипты и пихайте сами куда хотите.


По поводу вручную - неверно. Усе установки в linux содержит конфигурационные скрипты по настройке автозапуска. Эти скрипты можно клонировать и использовать для себя.
Ручное заполнение тоже не вполне верно - может заполняться приложениями. А то, что это текстовый файл - да - это файл конфигурации клиента - он текстовый.


Может я опять чего то в документации не досмотрел, но тогда скажите: Параметры порта, LINTER_MBX автоматически тоже настраиваются при использовании нескольких баз?
К примеру я попал в ситуацию когда эти значения были заняты первыми пришедшими к серваку.
Дальше идем на сторону клиента, где каждому клиенту приходится настраивать файл nodetab с параметрами сервака. Стоит только добавить новую базу или сменить порт и прогулка по всем клиентам обеспечена. К тому же просто поставить nodetab на клиента нельзя, поскольку он не отделен от пакета установки СУБД, а хотелось бы видеть отдельно, и что бы не скриптами это все регулировалось, а полноценным демоном. Так как разбираться где каждый "буратино" хранит скрипты от запуска своей базы и в каком месте при старте ОС он их вызывает очень не хочется.

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

Пойдем далее.
Сопряжение пользователей СУБД и пользователей ОС нет.

Сопряжение меток ОС с СУБД нет.

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

Бэкап. Удалось сделать только полный. Отключение триггеров нет, данный момент реализуется только путем наложения\создания всех проверок (уникальность, зависимоти, включение триггеров) после восстановления таблиц с данными. Для выгрузки отдельных частей БД пришлось писать скрипт, особенно для их восстановления, где как раз и потребовалась установка сиквенса, благо сиквенсы все по одной схеме делались и имена их легко тащились по имени таблицы, а так же поля для которых оные использовались с одним именем для всех таблиц. Тут надо сделать ремарку.
При восстановлении мне как таковой "ALTER SEQUENCE START WITH X" не подходит. Хотелось бы именно задание значения как в постгрессе pg_catalog.setval('seq', 123, true);

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

Да чуть не забыл. Версия 6.0.17.15 не собирается драйвер Qt под Qt 4 и МСВС 5, ругается на опцию компиляции, удаляем - собирается. А еще, решение с экспортом пути к директории Qt 4 в переменную QTDIR не самая лучшая идея для выбора версии Qt под которую собирается драйвер. Лучше идти стандартным путём qmake, qmake-qt4.

xz321 Одна база на один порт, почему и нет, все можно по логическим схемам развести, зачем плодить разные базы...

Наверно потому, что базы разные и в одну не слить)

Ермаков МихаилheleoВерсия 6.0.17.15 не собирается драйвер Qt под Qt 4 и МСВС 5, ругается на опцию компиляции, удаляем - собирается. А еще, решение с экспортом пути к директории Qt 4 в переменную QTDIR не самая лучшая идея для выбора версии Qt под которую собирается драйвер. Лучше идти стандартным путём qmake, qmake-qt4.

Проверили поведение.

1. qmake работает. Он создает отдельный Makefile. Потом достаточно запустить make -f Makefile
2. В нашей штатной сборке действительно есть один ключ от более нового компилятора. Его нужно убрать там где компилятор не поддерживает - как Вы, собственно, и сделали.

ключ -fno-strict-overflow

qmake - утилита для сборки приложения с использованием Qt 3 либо Qt4 в зависимости от того откуда она вызвана. Как правило выбор производится запуском скрипта для Qt 4 - qmake4 (qmake-qt4), либо прямого вызова qmake для Qt 3. У Вас в документации даже написано (readme.txt файл в паке с исходниками драйвера) "Before compile ensure, that QTDIR and QMAKE enviroment variables are set property.". Это вообще такой маленький грязный хак, что бы собралось с нужной версией. Хотя переменная QTDIR относится чисто к Qt 3, и в Qt 4 не применяется. К тому же у Вас уже создан makefile. После выполнения make он преобразуется в Makefile (с учетом qmake linter.pro и параметров makefile) который собственно и выполняется при компиляции. Если я попробую сходу запустить qmake linter.pro, а потом make -f Makefile, то результатом будет ошибка:


Ошибка кроется во включении необходимых параметров компиляции (include ../Definition, QTDIR) которые есть только в makefile, но не в linter.pro где этим вещам самое место.

Причем в прошлый раз (версия 6.0.15.3х) это использование qmake4 уже правилось. А в 6.0.17.15 вернулось обратно.
И моя самая любимая фича при сборке: Если кто то грохнет по незнанию ваш makefile присутствующий по умолчанию в драйвере, то уже ни как не собрать драйвер. Дальше начинается поиск дистрибутива СУБД или копии этой папки.

Вася Уткин,

Вася УткинЕрмаков Михаилпропущено...

Мы же не pg и не синхронизируемся с их репозиторием никак :).
А по разработчикам - они смогут самостоятельно поддерживать всю систему после потери доступа в помощи открытого сообщества? <оставим в стороне как это будет сделано технически :) >
Если интересуют какие-то фичи, то пишите - будем смотреть - когда и как реализовать. Если ваша компания сможет заказать доработку - можем выполнить заказ :).
Т.е. один раз Линтер-ВС 6.0 отпочковались от PostgreSQL 7.2 и забыли про PG, дальше исключительно своим путем?
Наша фирма продает железо на котором бывает крутиться ваша СУБД. А клиентам зачастую проще, быстрее и дешевле использовать СУБД с готовыми фичами, чем заказывать их :)

Линтер-ВС 6.0.1 живет своей жизнью и дальше, его часто приписывают к Линтер, но делает его другая контора которая собственно запилила МСВС - ВНИИНС. В частности была Линтер-ВС с постгрессом 7.2 и 8.х, и вроде проскакивала новая версия с 9.х, но в руках не держал.
К тому же, постгрес по умолчанию присутствует в AstraLinux с добавлением механизма мандатных меток и сопрягается с ОС при необходимости. Так же постгрес 9.х имеется еще в одной ОС, но по ней точно не скажу, что и как потому как в руки не попадала, но версия постгреса 9.0 или 9.1.

Ермаков МихаилheleoС примерами могу сказать так. Работать с BLOB не совсем ясно как. В примерах показана запись BLOB одноразовая, а если нужно записать в цикле через UPDATE дана только функция INSERT и REPLACE. С INSERT не сложилось, то ли баг, то ли что то еще. В итоге наращивание BLOB произвел через:

В пакете примеров для CALL интерфейса реализована функция LinterAOBJ (exlib.c). В документации по CALL интерфейсу в разделе о добавлении BLOB цитата - "Команда ABLB предназначена для добавления заданной порции BLOB-данных."
В примерах, к сожалению, приведена только команда AOBJ - хотя работают они одинаково. И последовательное обращение к этой функции обеспечивает последовательную загрузку данных в BLOB.
Кстати, а через какой интерфейс Вы пробовали работать?


Работаю я через Qt драйвер, а разговор шел непосредственно про SQL по работе с BLOB.

Ермаков МихаилheleoДальше идем на сторону клиента, где каждому клиенту приходится настраивать файл nodetab с параметрами сервака. Стоит только добавить новую базу или сменить порт и прогулка по всем клиентам обеспечена. К тому же просто поставить nodetab на клиента нельзя, поскольку он не отделен от пакета установки СУБД, а хотелось бы видеть отдельно, и что бы не скриптами это все регулировалось, а полноценным демоном. Так как разбираться где каждый "буратино" хранит скрипты от запуска своей базы и в каком месте при старте ОС он их вызывает очень не хочется.

Зависит от поставленной задачи. Интересно, а как будет в случае смены порта или инстанса в oracle? Не придётся перенастраивать клиентские?
Вариантов решения много - от размещения на неком разделяемом ресурсе общего файла до интеграции наших клиентских компонент в свой приложение (опять же для работы клиента нужно только 2 файла и никаких скриптов кроме запуска).

Тут нужно понимать две вещи:
1. Файл этот будет настраивать админ.
2. Выбор базы настроит пользователь в ПО сам, один раз и тогда когда надо будет, но без пункта 1 в Вашем случае к СУБД не подключиться никак.

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

Ермаков МихаилheleoНаличие скриптов создания системных таблиц базы которые надо затянуть вручную при создании своей базы. Нельзя внутрь спрятать сей момент? Я понимаю, что там можно отключить лишнее и не тащить, но выигрыша от этого я не заметил.
Я не знаю Вашей технологии развёртывания приложения, но согласитесь, это не сложно сделать. Кроме того, потребности у разных систем разные и, бывает, отключение полезно.
Кроме того, если Вы возьмёте почти :) любую систему, то получите что-то подобное - или развёртывание готовой БД с грудой мусора или создание БД с нуля с указанием конкретных параметров.
В нашем случае Вам ничто не мешает получить копию DEMO базы и тиражировать её изменяя параметры по необходимости. Да, для этого в UNIX пока не очень удобные средства, но это тоже временно (см. выше.)

Очень просто, для постгресса мы просто выполняем:


и радуемся развернутой базе. При этом не нужно беспокоится о системных кусках СУБД, для нас и админов этот момент полностью прозрачен. К тому же не нужно думать о тех же LINTER_MBX. Какие бы базы не стояли уже, мы с ними кроме как по имени не будем конфликтовать, а уникальное имя БД не проблема.

Ермаков МихаилheleoСопряжение пользователей СУБД и пользователей ОС нет.

В настоящий момент полностью работоспособна аутентификация через PAM и, локально, через систему.
http://www.linter.ru/documentation.php?ID=3057 - "создание пользователя".
Соответствующая информация должна будет быть добавлена в "архитектуру", но пока обновлённый документ не опубликован.

Хорошо. А возможности аутентификации по trust, ident? Меня вот ident интересует очень.

Ермаков МихаилheleoСопряжение меток ОС с СУБД нет.
Да, нет. Но это дискуссионный вопрос - что лучше. Что проще - понятно. А вот что лучше ....


Ермаков МихаилНу раз далее был разговор про безопасность... Как говорить про безопасность если её настройка лежит полностью на ПО? Получается что запустив inl я сам могу указать метку текущей сессии и под 0й меткой работать с 3й меткой безопасности?

heleoБэкап. Удалось сделать только полный.
А почему не получилось частичный?

heleoОтключение триггеров нет, данный момент реализуется только путем наложения\создания всех проверок (уникальность, зависимоти, включение триггеров) после восстановления таблиц с данными.
Есть. http://www.linter.ru/documentation.php?ID=3057 раздел "состояние триггера"


При выборе бэкапа отдельной таблицы происходит выгрузка данных этой таблицы, никаких сиквенсов при этом в ней нет как в случае бэкапа постгреса. Так же нет опции которая включит в этот бэкап SQL код по отключению триггеров на данную таблицу перед восстановление данных. Поэтому пришлось писать скрипт для частичного бэкапа БД, где добавлялись все необходимые параметры, и высчитываю сиквенсы SQL запросами после восстановления таблиц.

Ермаков МихаилheleoПри восстановлении мне как таковой "ALTER SEQUENCE START WITH X" не подходит. Хотелось бы именно задание значения как в постгрессе pg_catalog.setval('seq', 123, true);
А в чём криминал первой конструкции?

Представьте, что сиквенс от 1 до 100 с автоповтором, то есть некий диапазон допустимых к выдаче значений. И мне нужно сделать дамп а потом развернуть. Для восстановления сиквенса я использую


потому как максимальное предыдущее значение было 98. Вопрос: что будет после перехода через значение 100? В доках постгресса к примеру написано
Можно конечно использовать RESTART WITH или INC, но я не уверен, что это хороший подход при восстановлении дампа. По факту со стартом мы меняем сиквенс а не восстанавливаем его.

Ермаков МихаилheleoОпять же в сравнении с постгрессом, очень не хватает нотисов и особенно именованных констрейнов. К примеру если в коде несколько уникальных ключей, чеков, внешних ключей - выковыривать это не получится. Опять же, если делать обработку в каждой процедуре это просто ад.
нотисы - это комментарии? Если так, то сейчас они уже есть.
http://www.linter.ru/documentation.php?ID=3057 - "создание комментария".


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

Ермаков МихаилheleoПроцедуры нужно запускать с указанием имени схемы в которой она создана. При этом для представлений и таблиц еще можно сделать синоним и скрыть этот момент, но не с процедурами. Фактически не хватает схемы паблик.
Да, в настоящее время синонимов на процедуры нет. А вот схема такая недопустима по соображениям безопасности :).

А теперь самый цимус. Чем public Вам не угодил? Все постгрессы которые были у меня в руках имели public и не имели проблем с безопасностью. При этом все шикарно работало, мандатные метки на строки, столбцы, таблицы, доступ к процедурам. Всё это работало как под метками так и с возможностью их обхода при необходимости.

Ермаков Михаил Администратор (если это выделенное лицо) настроит возможность доступа ко всем базам. Эти базы пользователь создать на удалённой машине никак не может. А уж к какому алиасу коннектиться - это он и сам решит. При этом никто не мешает запустить (dbc_tcp) самоcтоятельно и настраивать себе как угодно. Действия лишние понадобятся, конечно, в любом случае.


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

Ермаков Михаил Понятно. В случае необходимости перечисления объектов для backup проблема некоторая есть. Потенциально она решается параметрами. lhbx это позволяет сделать, но сгенерить параметры для backup нет возможности. Вопрос понятен - учтём.
А зачем отключение триггеров? Или Вы хотите использовать backup только для данных в схеме, но не для самой схемы? Т.е. сохранить данные из таблиц и необходимые параметры (те же Sequences). Затем, в аварийном случае, почистить все таблицы и залить их данные из backup? Описана ли эта модель где-то? Мы можем её рассмотреть и сделать в будущем средства для подобных моделей.
Если это так, то становится понятна заинтересованность в установке значения последовательности в конкретное значение :). Учтём.

Да, только не всегда с зачисткой схем. Про модель ничего не скажу, так как у меня это в основном возникатет при сопровождении и разработке. Зачастую, бывает необходимо делать бэкап данных (только части или всех) для переноса на другой сервер, или при разработке есть необходимость внесения корректировки в БД при которой БД можно только пересоздать. При этом нужно сохранить часть данных и восстановить на новую схему. Вот тогда и появляется необходимость отключения триггеров.

Ермаков МихаилheleoНет не то. Это по факту фича , не знаю как у остальных СУБД, но очень удобная при наличии тяжелой бизнес логики в процедурном языке.
Понятно.
http://www.linter.ru/documentation.php?ID=2200 - раздел - генерация пользовательского исключения. Наверное, речь об этом.


Практически об этом, но:
1. У постгреса можно выкидывать не только исключения, но и передавать сообщения из БД без остановки выполнения.
2. Возможность передавать не формализованные сообщения. В вашем случае идет привязка к определенному коду и на выходе будет именно этот код. В итоге приходится лезть в таблицу за определением этого кода, так как просто выдать цифру для нас недопустимо. В постгресе на выход можно отправить текст по любому формату с любым содержанием. В Вашем случае только имеющийся код даже если это пользовательский вид исключения. Причем у Вас только исключения, тех же DEBUG, LOG, INFO, NOTICE, WARNING не хватает особенно при отладке (про дебагер знаем).
3. У Вас может возникнуть один и тот же вид исключения вызванный разными ситуациями, к примеру: два внешних ключа, оба должны быть не NULL, один из ключей пишут NULL или не существующий. Какой именно ключ выкинул исключение не ясно.

Ермаков Михаил А как это "с возможностью их обхода при необходимости" ? :)

К примеру, для функция это параметр при создании (опять же сравнивая с постгресом):

Ермаков Михаилheleo Вот только не стоит рассчитывать на то, что пользователь будет запускать самостоятельно dbc_tcp, не факт что ему дадут права на это (по факту и не дают). Тогда уж сразу возникает вопрос о безопасности работы с nodetab. Вдруг я захочу его подредактировать, а коллеги то и не заметят, что база не совсем та.
Верно. Но есть 2 момента.
1. Как администратор узнает - к какой БД обращается приложение? Т.е. как раз в PG у администратора пропадает возможность контроля за действиями приложения.
2. dbc может быть несколько и каждое приложение может использовать свой nodetab :) - совершенно не обязательно делать его общий.


Получается что контроль над приложением по доступу к БД есть, но управлять nodetab может кто угодно, либо администратор бегает и настраивает каждый ПК да еще под каждое приложение. При этом ни какой централизации управления доступом с различных хостов на сервере нет. Получается что nodetab будет выполнять свои функции нормально до тех пор пока в сети все ПК под жестким контролем админа и их количество не превышает некоего критичного порога обслуживания. А если ПК работает удаленно или все ПК без администрирования... Тогда "кто в лес кто по дрова", к томуже пользователь еще должен знать как настроить nodetab и как его запустить.

Ермаков Михаил В нашем случае это может быть стандартный запрос на получение ошибки - GETE из БД по коду. В этом случае Вы получите текстовое описание ошибки из таблиц ERRORS.


По факту так и сделано.
Хотя возникает вопрос: сработает ли данный запрос в блоке begin - commit, если произойдет ошибка, но rollback или commit не будут вызваны до GET?