Start a new topic
Not Taken

Обратная совместимость API Гидры

Многие из нас используют API Гидры для интеграции со своими информационными системами, кто-то переписал личный кабинет.


Когда выходит новая версия Гидры, нужно тратить массу времени, на проверку обратной совместимости по вызовам API скажем от версии 3.2 к версии 3.3.


Соотвественно, приходится перелопачивать кучу своего кода, что бы устранить вопросы совместимости. Тратится уйму времени. Часто изменения носят косметический характер.


Все таки Гидра продукт не "студенческий" и по-моему стал актуальным момент, когда нужно ввести стандарты или версии API, что бы после каждого обновления не переживать, что где-то остался скрипт который забыли адаптировать.




2 people like this idea

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


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

Проблема в том что мы с вами работаем на одном уровне. Если бы у вас было API для клиентских приложений, которое бы абстрагировалось от вашей внутренней кухни мы бы могли менять ядро как угодно.


К примеру клиентам нужна функция которая по лицевым выдавала бы структуру со всеми данными пользователя. Сейчас любое ваше изменение приводит к тому что нам приходится переписывание. Такое недавно было когда вы в таблицах поменяли USER_ID на SUBJECT_ID или обратно.


Если бы было API для клиентов, то мы бы вызывали не системный вызов, а вызывали бы функцию прокладку у которой названия параметров не менялись бы или поддерживались оба варианта.


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


Просто с нашей точке зрения, если вы удалили функцию это значит что у нас функционал перестал работать полностью. Если есть какие то изменения то либо потребуются изменения либо вообще не затронет работу. Ну и если вы добавили новые функции то для текущего функционала это все равно.


Такое банальное изменение сильно упростило бы нам миграцию на новую версию.

Алексей,100 раз поддержу. Чтобы что-то настроить самостоятельно элементарное нет даже описание логики работы и где, что прописывать. Уверен, У коллегам из Латеры задают одни и те же вопросы по кругу ВСЕ их клиенты. 

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


 +1, абсолютно аналогично.

При наличии своего личного кабинета и своей CRM, в которой реализовано 100500 взаимодействий с гидрой, и пары десятков различных важных скриптов для различной автоматизации, обновлений ожидаешь, как страшного сна ;(

Про разделы поддерживаю. Все приходиться узнавать у ТП. Особенно доставляет изменение параметров или просто удаление функций. Про изменение логики работы пакетов вообще молчу, угадай как оно теперь у нас будет работать :)


На текущий момент задача внесения изменений в программную документацию не является приоритетной. 

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

Коллеги, прошу не отвлекаться от основной темы. Запрос все таки был по наследственности API и сохранения обратной совместимости.

По хотелкам HARD создавайте пожалуйста отдельный запрос.

Так же еще добавлю такой момент, изменения указаны только между версиями, если происходит обновление сразу через несколько версий, то необходимо анализировать все изменения между всеми промежуточными версиями, при большом количестве используемых пакетов, задача требует значительных временных затрат

Каждое обновление доставляет кучу проблем из-за того что система не едина, есть куча модулей настраиваемых отдельно, своими файлами конфигурации, hard так вообще настраивается в 3 местах(FreeRadius, конфигурация hard, и настройка сетевой службы в ООС)

У нас такая же проблема, переход на новые версии достаточно болезненный.


Приходится вручную лопатить все ваши логи по всем скриптам. Хотя бы разбейте их на 3 раздела:

Критичные изменения - удаление или изменение старых таблиц, функции или их параметров.

Важные - добавление новых параметров в старые функции.

Обычные - добавление новых функций.


Это как минимум сократит время на внедрение новых версий.


Но в обще было бы здорово иметь нормальный API.

Коллеги, программная документация доступна в wiki - http://wiki.latera.ru/pages/viewpage.action?pageId=21397588

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

Вы также можете получить информацию об определенном представлении, пакете или таблице по обращению в тех. поддержку. 


Помимо прочего, вам всегда перед установкой новой версии предлагается ознакомиться с ней через обновление тестовой базы. Таким образом, у вас есть возможность отладить все стыковки, чтобы обновление основной базы прошло "безболезненно". 

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

Login or Signup to post a comment