-
-
Notifications
You must be signed in to change notification settings - Fork 20
chore: migrate database from MySQL to PostgreSQL #61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Thanks for creating this PRWe'll review it as soon as possible. If there are any unresolved review comments, feel free to resolve them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @MIHIR2006, I'm Gemini Code Assist1! 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 undertakes a significant infrastructure change by migrating the project's database from SQLite to PostgreSQL. The primary goal is to enhance the database's robustness, scalability, and feature set. This migration involved comprehensive updates across the codebase, including backend database connection logic, frontend Prisma schema, and detailed developer documentation to ensure a smooth transition and setup for local development environments.
Highlights
- Database Migration: The project's database has been migrated from SQLite to PostgreSQL, enhancing robustness and scalability.
- Configuration Updates: Backend and frontend configurations, including environment variables and ORM settings, were updated to support PostgreSQL.
- Developer Experience: The README.md was significantly updated with detailed instructions for local PostgreSQL setup using Docker, Prisma client setup, and database inspection tools.
- Dependency Changes: New Python dependencies (
psycopg2-binary,email-validator) were added to facilitate PostgreSQL connectivity and related functionalities.
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.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
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. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request successfully migrates the project's database from SQLite to PostgreSQL, a significant improvement for scalability and production readiness. The changes include updating backend and frontend database configurations, adding the necessary PostgreSQL driver, and providing detailed setup instructions in the README.md. A minor point of attention is the PR title, which mentions a migration from MySQL, while the code indicates a migration from SQLite; updating the title would enhance clarity.
The implementation is solid, particularly the addition of pool_pre_ping=True for robust connection handling and the explicit DATABASE_URL check in the backend. I have a couple of suggestions to improve documentation consistency and maintain focus in pull requests, which are detailed in the comments below.
| 4. **Start PostgreSQL locally (recommended: Docker)** | ||
| ```bash | ||
| # Start a local PostgreSQL 16 container on port 5432 | ||
| docker run --name stockvision-postgres \ | ||
| -e POSTGRES_USER=svuser -e POSTGRES_PASSWORD=svpass -e POSTGRES_DB=stockvision \ | ||
| -p 5432:5432 -d postgres:16 | ||
|
|
||
| # Set the same DATABASE_URL in your shell (PowerShell example) | ||
| # $env:DATABASE_URL="postgresql://svuser:svpass@localhost:5432/stockvision" | ||
| ``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The documentation for setting up the local database has inconsistent credentials, which could be confusing for new developers.
For example:
- The
backend/.envexample suggestspostgresql://user:password@...(line 102). - This
docker runcommand usessvuser/svpass(line 109). - The PowerShell example uses
svuser:svpass(line 113). - Later, the Unix shell example for the frontend uses
user:passwordagain (line 129).
To improve clarity and reduce setup friction, I recommend using a single, consistent set of example credentials (e.g., svuser/svpass) across all documentation examples, including the .env file examples.
| "fastapi>=0.104.1", | ||
| "uvicorn[standard]>=0.24.0", | ||
| "pydantic>=2.5.0", | ||
| "email-validator>=2.1.0.post1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While adding email-validator might be necessary, it seems unrelated to the primary goal of this pull request, which is migrating the database to PostgreSQL. To maintain clear and focused commits, it's a good practice to handle unrelated dependency changes in a separate pull request. This helps with code reviews and tracking changes.
Migrated the project database to PostgreSQL