В-третьих, я советую устанавливать GLPI не из репозиториев, а с сайта GLPI, поскольку это позволит провести чистую установку, без «паровоза» из ненужных зависимостей и программ.
То, что панацеи не существует — это не оспаривается. Я другое не могу понять. Давайте на примере.
Есть у нас в программе возможность, например, создать пользователя. Для этого надо:
1. Запустить программу (открыть сайт в браузере, запусть линк с рабочего стола или бинарник)
2. Авторизоваться
2.1 Ввести имя пользователя в поле usernname
2.2. Ввести пароль в поле password
2.3 Нажать кнопку «ОК»
4. Нажать кнопку btnusers
5. Ввести новое имя пользователя в поле newuser
6. Ввести новый пароль в поле newpassword
7. Ввести еще что-то в поле somefield
8. Нажать кнопку «ОК».
В результате этого в базе данных должна появиться запись с новосозданным именем и, например, хешем нововведенного пароля. Если запись создана — тест прошел успешно, если запись не создана — тест провален.
При этом тест будет провален во всем многообразии случаев — и при переполнении места на сервере БД, и при недоступности БД, и при срабатывании множества проверок по пути начиная от авторизации. В смысле, какая бы ошибка по пути не произошла — все равно в базе данных не будет записи о свежесозданном пользователе и робот сигнализует об ошибке. А с причинами возникновения конкретной ошибки уже будет разбираться человек.
Кхм. Объясните мне, пожалуйста, как неспециалисту. Я пишу тест, который запускает приложение, выполняет в нем ряд действий — нажимает кнопки, заполняет поля ввода и т.д. — и ожидает какой-то результат. Например, запись в базе данных. Соответственно, если запись в базе не появилась, значит что-то пошло не так, тест провален. Разве нет?
Напоминаю, я неспециалист поэтому просьба не пинать ногами, если глупость спросил.
В общем и целом я лямку за Firebird тяну если что :) Но упоминаю возможности всех серверов, так как пытаюсь быть более объективным, чем автор статьи. Честно признаюсь, что об ограничениях TEXT для MySQL не в курсе; для Firebird-овского BLOB SUB_TYPE 1 — в курсе.
При этом сравнить работу даже просто длинных строк — не так просто. Даже если выделить обсуждаемым СУБД одинаковые, допустим, виртуалки, как минимум встанут вопросы конфигурации серверов. Плюс отдельно — режимы работы: только вставка или вставка/обновление/удаление, количество последовальных чтений, количество одновременных чтений, количество одновременных чтений с одновременными же обновлениями/удалениями данных, то же самое — с проверкой достоверности (должен ли пользователь А видеть данные, которые пользователь Б начал удалять после того, как пользователь А начал их просматривать).
Возьметесь за такое сравнение? Я — нет, ибо недостаточно компетентен в MySQL/PostgreSQL для правильного написания теста под них.
У firebird-a есть IBExpert. Не является частью собствено firebird, коммерческий (но бесплатен для тех у кого локаль win1251; на линуксе под вайном работает нормально).
Ни одна из этих баз данных сейчас не поддерживает CHECK ограничения
> То есть как это?
Вот-вот. Из-за таких вот такие формулировок статья выглядит мягко говоря маркетинговой чухней. Исходя из этого категорического утверждения, Firebird тоже не поддерживает CHECK-и, а пробегаясь дальше по тексту — так же не поддерживает ACID. Да, прямо об этом не написано, но формилируется именно так.
Или еще вот пассаж: то что у PostgreSQL поддерживаются большые строки — это большой плюс и вообще «фи» остальным, которые «только 64 кб». Стыдливо замалчивая при этом TEXT для mysql и BLOB SUB_TYPE 1 для firebird. Но зато рядом
как известно любому администратору баз данных, стоит с опаской относиться к слишком большим и неограниченным возможностям. Мы советуем руководствоваться здравым смыслом при создании таблиц и добавлении индексов
В целом — да, будет работать по такой схеме. Само собой за кадром остается масса деталей, которые описаны в релизнотах. Например, если в приложении есть запросы со смешанными явными и неявными джойнами (select table1.f1, table2.f2, table3.f3 from table1, table2 join table3 on… where ...), то они работать не будут. Аутентификацию опять же скорее всего надо будет перенастраивать.
Никак не проапргейдить: очевидный логичный результат того, что в security2.fdb хранятся только хеши, по которым пароли не восстановить. И способы хранения в 2.5 и в 3.0 кардинально отличаются, что делает невозможным прямой перенос хешей.
Дополню свой ответ цытатой из релизнот (раздел Server Modes, страница 7):
When «database name» does not contain a network protocol but just the database name, the Remote provider
rejects it and the Engine12 provider comes to the fore and tries to open the named database file. If it succeeds,
we get an embedded connection to the database.
Note
A special “embedded library” is no longer required. To make the embedded connection, the standard client
loads the appropriate provider and becomes an embedded server.
Зная имя и пароль для доступа к серверу можно много чего сделать. Запустить расчет числа пи до n-ного знака, например. Во многих потоках. Это тоже проблема с безопасностью?
Не стОит выбрасывать привычный Вам инструмент, конечно же, хотя интересностей в тройке много. Главные описаны во втором разделе релизнот (две страницы крупным шрифтом) — полный SMP в варианте суперсервер, расширенная индивидуальная конфигурация баз, расширенная статистика и диагностика, SQL-пакеты, оконные и статистические функции, двунаправленные курсоры…
Проблема книг в том, что код из них надо перепечатывать, а из интернета можно скопипастить :) Вот только очень много кода в интернете плохого качества, а новички в конкретной области об этом не знают и регулярно делают одни и те же ошибки. Вот автор и пытается объяснить подоходчивее.
Еще одна причина для появления этой статьи — это то, что авторы упомянутого вами FIBPlus как в воду канули. Новые версии компонент не выходят, старые законно купить уже не у кого. Опять же у многих возникает вопросс — что использовать вместо них. Особенно в свете грядущего выхода Firebird 3.0.
В сообществе firebird давно витала идея насчет серии таких статей и примеров приложений для начинающих — чтобы не разжевывать каждый раз типичные ошибки людей, которые, например, уверены что их запросы выполняются «без транзакций» или что новое значения первичного ключа надо получать как max(id) +1 в клиентском приложении. Это — первая пробная статья из такой (планируемой) серии. Delphi — потому что самый частоиспользуемый (или один из, как минимум) инструмент в связке с firebird. На хабре — потому что популярный технический ресурс.
Я просто оставлю это здесь.
Есть у нас в программе возможность, например, создать пользователя. Для этого надо:
1. Запустить программу (открыть сайт в браузере, запусть линк с рабочего стола или бинарник)
2. Авторизоваться
2.1 Ввести имя пользователя в поле usernname
2.2. Ввести пароль в поле password
2.3 Нажать кнопку «ОК»
4. Нажать кнопку btnusers
5. Ввести новое имя пользователя в поле newuser
6. Ввести новый пароль в поле newpassword
7. Ввести еще что-то в поле somefield
8. Нажать кнопку «ОК».
В результате этого в базе данных должна появиться запись с новосозданным именем и, например, хешем нововведенного пароля. Если запись создана — тест прошел успешно, если запись не создана — тест провален.
При этом тест будет провален во всем многообразии случаев — и при переполнении места на сервере БД, и при недоступности БД, и при срабатывании множества проверок по пути начиная от авторизации. В смысле, какая бы ошибка по пути не произошла — все равно в базе данных не будет записи о свежесозданном пользователе и робот сигнализует об ошибке. А с причинами возникновения конкретной ошибки уже будет разбираться человек.
В чем я неправ?
Напоминаю, я неспециалист поэтому просьба не пинать ногами, если глупость спросил.
При этом сравнить работу даже просто длинных строк — не так просто. Даже если выделить обсуждаемым СУБД одинаковые, допустим, виртуалки, как минимум встанут вопросы конфигурации серверов. Плюс отдельно — режимы работы: только вставка или вставка/обновление/удаление, количество последовальных чтений, количество одновременных чтений, количество одновременных чтений с одновременными же обновлениями/удалениями данных, то же самое — с проверкой достоверности (должен ли пользователь А видеть данные, которые пользователь Б начал удалять после того, как пользователь А начал их просматривать).
Возьметесь за такое сравнение? Я — нет, ибо недостаточно компетентен в MySQL/PostgreSQL для правильного написания теста под них.
> То есть как это?
Вот-вот. Из-за таких вот такие формулировок статья выглядит мягко говоря маркетинговой чухней. Исходя из этого категорического утверждения, Firebird тоже не поддерживает CHECK-и, а пробегаясь дальше по тексту — так же не поддерживает ACID. Да, прямо об этом не написано, но формилируется именно так.
Или еще вот пассаж: то что у PostgreSQL поддерживаются большые строки — это большой плюс и вообще «фи» остальным, которые «только 64 кб». Стыдливо замалчивая при этом TEXT для mysql и BLOB SUB_TYPE 1 для firebird. Но зато рядом
«Грустно все это»©
Еще одна причина для появления этой статьи — это то, что авторы упомянутого вами FIBPlus как в воду канули. Новые версии компонент не выходят, старые законно купить уже не у кого. Опять же у многих возникает вопросс — что использовать вместо них. Особенно в свете грядущего выхода Firebird 3.0.
Мопед не мойАвтор не я, но осмелюсь ответить.В сообществе firebird давно витала идея насчет серии таких статей и примеров приложений для начинающих — чтобы не разжевывать каждый раз типичные ошибки людей, которые, например, уверены что их запросы выполняются «без транзакций» или что новое значения первичного ключа надо получать как max(id) +1 в клиентском приложении. Это — первая пробная статья из такой (планируемой) серии. Delphi — потому что самый частоиспользуемый (или один из, как минимум) инструмент в связке с firebird. На хабре — потому что популярный технический ресурс.
Еще вопросы? :)