Design and implementation of a relational data model supported in Postgres Sakai Learning Management System

Abstract

This thesis aims to study database portability in the context of the large, enterprise legacy code that is Sakai LMS, which is a free, community-source, educational software platform designed to support teaching and research, and has beenunder continuous development and production for the past 20 years.The application is committed to database portability and currently supports Oracle and MySQL and wishes to support PostgreSQL going forward. The application mixes hand-constructed SQL, templated SQL, and data persistence by a JavaORM solution, JPA. The goal is not to rewrite the application to use a new wayto generate SQL but to look at the effort required to convert all SQL approachesfrom one dialect to another.To inform and help accomplish this engineering task, this thesis will have a deeperexamination of how the application executes all database-related operations andexplore how the SQL dialects diverge among the various databases. This paperwill also look at strategies to add a new database dialect or convert SQL from onedialect to another, exploring the jOOQ library and then testing its effectiveness inthis internship’s problem.This thesis work contributed to the progress in the challenge of inserting the PostgreSQL dialect into SakaiLMS:• Sakai LMS can now start up with a PostgreSQL database, using a MySQLSQL service that gets translated to Postgres.• The proposal of an architecture that can build the base for a translationsserver that enables Sakai LMS to be fully compatible with Postgres and,thanks to the way jOOQ’s SQL translator works, other relational databases,without modifying the SQL service.In addition to that, this work also allowed us to conclude that jOOQ’s SQL translator works for most translations, but not always. So it’s necessary to modifyany jOOQ SQL translator layer to cope with the errors it throws. As we couldconclude, manual edition and approval of unsuccessful translations are enough.Another conclusion taken was that the SQL service in Sakai isn’t the only entityresponsible for executing SQL statements in Sakai. This turned out to be a limitation in the work’s results because the proposed architecture wasn’t expectingthat behavior from Sakai.

Esta tese tem como objetivo estudar a portabilidade de bases de dados no contexto de large, enterprise legacy code que é o Sakai LMS, que é uma plataforma de software educacional gratuita, de código aberto, projetada para apoiar o ensino e a pesquisa, e tem sido alvo de contínuo desenvolvimento e produção nos últimos 20 anos.A aplicação está comprometida com a portabilidade de bases de dados e atualmente suporta Oracle e MySQL e deseja oferecer começar a suportar PostgreSQL. A aplicação combina SQL construído manualmente, SQL modelado e persistência de dados por uma solução ORM em Java, JPA. O objetivo não é reescrever a aplicação para usar uma nova maneira de gerar SQL, mas observar o esforço necessário para converter todas as abordagens de SQL de um dialeto para outro.Para informar e ajudar a realizar esta tarefa de engenharia, esta tese examinará de como a aplicação executa todas as operações relacionadas com a sua base de dados e explorar como os dialetos SQL divergem entre as várias bases de dados. Este trabalho também averiguará estratégias para adicionar um novo dialeto de banco de dados ou converter SQL de um dialeto para outro, explorando a biblioteca jOOQ e testando sua eficácia no problema deste estágio.O trabalho desta tese contribuiu para o avanço no desafio de inserir o dialeto PostgreSQL em Sakai LMS:• Sakai LMS agora pode inicializar com uma base de dados PostgreSQL, usando o serviço de SQL em MySQL que é traduzido para PostgreSQL.• A proposta de uma arquitetura que possa servir de base para um servidor de tradução que permita Sakai LMS ser totalmente compatível com PostgreSQL e, graças ao funcionamento do tradutor de SQL do jOOQ, outros bancos de dados relacionais, sem modificar o serviço de SQL.Além disso, este trabalho também nos permitiu concluir que o tradutor SQL do jOOQ funciona para a maioria das traduções, mas não sempre. Portanto, é necessário modificar qualquer camada com o tradutor de SQL do jOOQ para lidar com os erros que este gera. Como pudemos concluir, a edição manual e a aprovação de traduções malsucedidas são suficientes.Outra conclusão tirada foi que o serviço de SQL em Sakai não é a única entidade responsável pela execução de instruções SQL em Sakai. Isso acabou sendo uma limitação nos resultados do trabalho, pois a arquitetura proposta não esperava esse comportamento na aplicação.