Media is too big
VIEW IN TELEGRAM
Как перенести приложение с Oracle Forms в веб, сохранив бизнес-логику и привычное поведение экранных форм?
В видео разбираем технологию автоматизированного переноса на Go и показываем её работу на демонстрационном приложении.
► Рассказываем, почему замены СУБД недостаточно и что усложняет ручной перенос.
Показываем, как из файлов .fmb извлекаются метаданные, SQL и PL/SQL-код, как преобразуются триггеры и как связаны JSON, сервер на Go и браузерный интерфейс.
В представленном решении около 70% работ выполняется автоматически.
Оставшаяся часть — адаптация интерфейса и разработка Go-компонентов для конкретных форм.
В практической части Дмитрий Пшеничный из отдела разработки сравнивает исходное и перенесённое приложения: выполнение SQL-запросов, добавление и обновление записей, вызов хранимых процедур и функций, вывод результатов в интерфейс.
Видео также доступно на (в них есть также и таймкоды):
VK
Dzen
YouTube
#OracleForms #Go #Миграция #БазыДанных #PLSQL
В видео разбираем технологию автоматизированного переноса на Go и показываем её работу на демонстрационном приложении.
► Рассказываем, почему замены СУБД недостаточно и что усложняет ручной перенос.
Показываем, как из файлов .fmb извлекаются метаданные, SQL и PL/SQL-код, как преобразуются триггеры и как связаны JSON, сервер на Go и браузерный интерфейс.
В представленном решении около 70% работ выполняется автоматически.
Оставшаяся часть — адаптация интерфейса и разработка Go-компонентов для конкретных форм.
В практической части Дмитрий Пшеничный из отдела разработки сравнивает исходное и перенесённое приложения: выполнение SQL-запросов, добавление и обновление записей, вызов хранимых процедур и функций, вывод результатов в интерфейс.
Видео также доступно на (в них есть также и таймкоды):
VK
Dzen
YouTube
#OracleForms #Go #Миграция #БазыДанных #PLSQL
Forwarded from Ассоциация Разработчиков СУБД RuDB
В этом посте я бы хотел кратко рассказать, чем же отличаются Digital Q.DataBase и RuDB и какие задачи решает каждый из этих продуктов.
Digital Q.DataBase — коммерческая СУБД для корпоративных заказчиков. Одна из ключевых задач, которую она решает: как перейти с Oracle и Microsoft SQL Server, сохранив прикладную логику и минимизировав переписывание кода?
У Ассоциации разработчиков СУБД, которая развивает RuDB, другой исходный вопрос: зачем каждому российскому разработчику СУБД на базе PostgreSQL самостоятельно реализовывать одни и те же технологии?
У таких разработчиков много общих задач: безопасность, перенос данных, повышение производительности, совместимость с российскими приложениями.
Если каждую из них все решают отдельно, значительная часть усилий уходит на повторение одной и той же работы.
Идея ассоциации — объединить усилия в этой общей части.
Совместно развивать технологическую основу, на которой участники смогут создавать собственные продукты и конкурентные преимущества.
Здесь важно различать саму ассоциацию и RuDB. Ассоциация объединяет разработчиков, а RuDB — технологический результат их совместной работы.
Подробнее о возможностях RuDB можно прочитать на сайте database.ru.
А сейчас давайте разберём один конкретный пример — совместимость с функциональностью пакетов Oracle.
Представим корпоративное приложение, которое много лет работало на Oracle.
Внутри него есть такой фрагмент PL/SQL-кода, как на слайде (2).
Здесь используется пакет DBMS_AQ — механизм Oracle Advanced Queuing.
Приложение формирует сообщение и вызовом DBMS_AQ.ENQUEUE помещает его в очередь.
Теперь мы хотим перенести это приложение на обычный PostgreSQL.
В стандартной поставке PostgreSQL такого пакета нет.
И задача не сводится к тому, чтобы заменить название процедуры или поправить синтаксис.
За этим вызовом стоит определённое поведение: постановка сообщения в очередь, его последующая обработка, связь с транзакцией.
Разработчику нужно подобрать замену и проверить, что она обеспечивает необходимое приложению поведение.
Это может потребовать изменений в коде, а иногда — и в архитектуре.
Например, если принято решение использовать внешнюю систему обмена сообщениями.
Именно здесь становится понятна ценность таких наработок в RuDB.
В RuDB реализована функциональность работы с очередями, соответствующая этому примеру.
Вместо пакетного вызова DBMS_AQ.ENQUEUE используется функция dbms_aq_enqueue.
Но это не означает, что исходный PL/SQL-код можно перенести без изменений.
Код потребуется адаптировать, а работу с параметрами, типами данных и транзакциями — проверить.
При этом разработчику уже не нужно с нуля создавать сам механизм очереди.
Он может использовать готовую реализацию и сосредоточиться на адаптации приложения.
RuDB сокращает объём работы по воспроизведению необходимой функциональности при миграции.
Digital Q.DataBase идёт дальше в части совместимости с исходным приложением: задача продукта — сохранить не только нужную функциональность, но и исходный код там, где поддерживается соответствующая совместимость.
В примере на слайде (2) это означает сохранение привычного пакетного вызова из PL/SQL.
Таким образом, различие можно сформулировать так:
В RuDB мы используем готовую функциональность и адаптируем под неё код.
В Digital Q.DataBase мы стремимся сохранить и функциональность, и исходный код приложения.
Поэтому RuDB нельзя рассматривать просто как бесплатную версию Digital Q.DataBase.
У них разные задачи:
RuDB даёт разработчикам общую технологическую основу, а Digital Q.DataBase помогает корпоративным заказчикам переносить существующие приложения с минимальными изменениями.
#RuDB #QDB #СУБД #НовостиСУБД #Oracle #PLSQL #Импортозамещение
Digital Q.DataBase — коммерческая СУБД для корпоративных заказчиков. Одна из ключевых задач, которую она решает: как перейти с Oracle и Microsoft SQL Server, сохранив прикладную логику и минимизировав переписывание кода?
У Ассоциации разработчиков СУБД, которая развивает RuDB, другой исходный вопрос: зачем каждому российскому разработчику СУБД на базе PostgreSQL самостоятельно реализовывать одни и те же технологии?
У таких разработчиков много общих задач: безопасность, перенос данных, повышение производительности, совместимость с российскими приложениями.
Если каждую из них все решают отдельно, значительная часть усилий уходит на повторение одной и той же работы.
Идея ассоциации — объединить усилия в этой общей части.
Совместно развивать технологическую основу, на которой участники смогут создавать собственные продукты и конкурентные преимущества.
Здесь важно различать саму ассоциацию и RuDB. Ассоциация объединяет разработчиков, а RuDB — технологический результат их совместной работы.
Подробнее о возможностях RuDB можно прочитать на сайте database.ru.
А сейчас давайте разберём один конкретный пример — совместимость с функциональностью пакетов Oracle.
Представим корпоративное приложение, которое много лет работало на Oracle.
Внутри него есть такой фрагмент PL/SQL-кода, как на слайде (2).
Здесь используется пакет DBMS_AQ — механизм Oracle Advanced Queuing.
Приложение формирует сообщение и вызовом DBMS_AQ.ENQUEUE помещает его в очередь.
Теперь мы хотим перенести это приложение на обычный PostgreSQL.
В стандартной поставке PostgreSQL такого пакета нет.
И задача не сводится к тому, чтобы заменить название процедуры или поправить синтаксис.
За этим вызовом стоит определённое поведение: постановка сообщения в очередь, его последующая обработка, связь с транзакцией.
Разработчику нужно подобрать замену и проверить, что она обеспечивает необходимое приложению поведение.
Это может потребовать изменений в коде, а иногда — и в архитектуре.
Например, если принято решение использовать внешнюю систему обмена сообщениями.
Именно здесь становится понятна ценность таких наработок в RuDB.
В RuDB реализована функциональность работы с очередями, соответствующая этому примеру.
Вместо пакетного вызова DBMS_AQ.ENQUEUE используется функция dbms_aq_enqueue.
Но это не означает, что исходный PL/SQL-код можно перенести без изменений.
Код потребуется адаптировать, а работу с параметрами, типами данных и транзакциями — проверить.
При этом разработчику уже не нужно с нуля создавать сам механизм очереди.
Он может использовать готовую реализацию и сосредоточиться на адаптации приложения.
RuDB сокращает объём работы по воспроизведению необходимой функциональности при миграции.
Digital Q.DataBase идёт дальше в части совместимости с исходным приложением: задача продукта — сохранить не только нужную функциональность, но и исходный код там, где поддерживается соответствующая совместимость.
В примере на слайде (2) это означает сохранение привычного пакетного вызова из PL/SQL.
Таким образом, различие можно сформулировать так:
В RuDB мы используем готовую функциональность и адаптируем под неё код.
В Digital Q.DataBase мы стремимся сохранить и функциональность, и исходный код приложения.
Поэтому RuDB нельзя рассматривать просто как бесплатную версию Digital Q.DataBase.
У них разные задачи:
RuDB даёт разработчикам общую технологическую основу, а Digital Q.DataBase помогает корпоративным заказчикам переносить существующие приложения с минимальными изменениями.
#RuDB #QDB #СУБД #НовостиСУБД #Oracle #PLSQL #Импортозамещение
🔥8