Add support for Multiple DB Drivers in OGA Service

[ginaxu1]

Closes #246
Closes #250

Summary

Introduce a driver-agnostic DB layer for the OGA service per the interface + factory pattern. Add official support for PostgreSQL while maintaining SQLite as the default option for local development and backward compatibility, ensuring that the core storage logic never needs to be modified when adding new DB engines in the future

Changes

OGA Backend

• oga/internal/connector.go: introduce the DBConnector interface to abstract GORM connection logic
• oga/internal/sqlite_connector.go & oga/internal/postgres_connector.go: Created dedicated files to isolate driver-specific dependencies and centralize DSN (Data Source Name) construction for each database type
• oga/internal/factory.go: implement NewDBConnector, a factory function that handles the switch mechanism to instantiate the correct driver based on the environment configuration
• oga/internal/store.go: refactor NewApplicationStore to completely decouple it from specific GORM drivers. It now relies entirely on the factory and interface, removing all hardcoded driver imports
• oga/internal/config.go: add new configuration fields to support database driver selection (OGA_DB_DRIVER) and PostgreSQL-specific connection parameters (Host, Port, User, Password, DB Name, and SSL Mode).
• oga/go.mod & oga/go.sum: add PostgreSQL driver dependencies

Infrastructure & Scripts

• Dockerfile: update to include the new database environment variables, ensuring they are available within the containerized environment
• docker-compose.yml: add database configuration blocks for all three OGA service instances (nsw-oga-npqs, nsw-oga-fcau, and nsw-oga-ird) to allow them to connect to external or containerized PostgreSQL instances
• start-dev.sh: update the local development script to pass through the new database environment variables to the OGA processes
• start-docker.sh: update the startup summary output to explicitly display which database driver is currently active for better visibility during troubleshooting.

Configuration

• oga/.env.example & .env.example: update templates with detailed sections for PostgreSQL configuration, including default values for local setup (e.g., sslmode=disable)

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant architectural enhancement to the OGA application by implementing a generic database connection mechanism. This change abstracts the underlying database technology, enabling the application to seamlessly switch between SQLite and PostgreSQL. The primary impact is increased flexibility for deployment scenarios, allowing users to choose a database solution that best fits their operational needs without requiring code modifications. The update involves changes across configuration, dependency management, and core database initialization logic.

Highlights

• Generic Database Support: The OGA application now supports both SQLite and PostgreSQL as database drivers, allowing for greater flexibility in deployment and data management.
• Configurable Database Settings: New environment variables have been introduced to configure the database driver (OGA_DB_DRIVER) and specific connection details for both SQLite (OGA_DB_PATH) and PostgreSQL (OGA_DB_HOST, OGA_DB_PORT, OGA_DB_USER, OGA_DB_PASSWORD, OGA_DB_NAME, OGA_DB_SSLMODE).
• Dynamic Database Initialization: The internal application store has been refactored to dynamically select and initialize the appropriate GORM dialector (SQLite or PostgreSQL) based on the configured OGA_DB_DRIVER.
• Updated Development and Deployment: Docker Compose, Dockerfile, and local development scripts have been updated to incorporate and utilize the new generic database configuration, ensuring consistent behavior across environments.
• Documentation Updates: The README.md file has been updated to reflect the new database options, including usage examples and a comprehensive list of new environment variables.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request implements support for PostgreSQL as a database backend alongside the existing SQLite, which is a great enhancement. The changes are spread across configuration files, Docker setup, and the Go application code to allow for a generic database connection. My review focuses on security and maintainability aspects introduced by these changes. I've identified a critical security issue with hardcoded credentials in the Dockerfile, and other high/medium severity issues related to potential credential leakage in logs, weak default passwords, and code duplication in configuration. Please find detailed comments below.

[sthanikan2000]

@ginaxu1 can you move the new connectors in to a separate folder inside internal

And don't we need to update the root .env.docker.example?

[sthanikan2000]

@ginaxu1 did you tested with postgres configuration?

[sthanikan2000]

LGTM!