docs: add Supabase schema and seed instructions#309
docs: add Supabase schema and seed instructions#309shrav784 wants to merge 2 commits intoAOSSIE-Org:mainfrom
Conversation
WalkthroughUpdated README's "Data Population" section to use a plain Supabase URL, added explicit SQL to create Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@README.md`:
- Around line 210-215: The README currently seeds users in Step 3 and then runs
sql.txt in Step 4 which re-inserts the same rows without conflict handling;
update the instructions so either Step 4 runs before Step 3 or (preferably)
modify sql.txt to make the INSERT into the users table idempotent by adding ON
CONFLICT handling for the unique keys (username and email) so repeated runs
won’t fail; reference the users table and its username/email unique constraints
and the files/steps named "Step 3", "Step 4", and "sql.txt" when making the
change.
- Around line 199-207: The README CREATE TABLE public.users is missing the
is_online and last_seen columns and marks role as nullable; update the SQL in
the README to match the backend User model in Backend/app/models/models.py by
adding is_online BOOLEAN NOT NULL DEFAULT FALSE and last_seen TIMESTAMP WITH
TIME ZONE (nullable or with the same default as the model) and make role TEXT
NOT NULL (or include the same DEFAULT used in the User model), ensuring column
names, types, nullability, and defaults mirror the User model so ORM queries
won’t fail.
- Line 200: The README's SQL example uses gen_random_uuid() but doesn't mention
the pgcrypto prerequisite; update the SQL block to include a one-liner note (or
SQL command) that pgcrypto must be enabled (e.g., CREATE EXTENSION IF NOT EXISTS
pgcrypto;) before using gen_random_uuid(), and add a brief comment mentioning
pgcrypto so readers know to enable it to avoid function-not-found errors.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 95d4c02c-7111-4079-87c0-240d19986cf4
📒 Files selected for processing (1)
README.md
README.md
Outdated
| INSERT INTO public.users (username, email, role, bio) | ||
| VALUES | ||
| ('creator1', 'creator1@example.com', 'creator', 'Bio of creator1'), | ||
| ('brand1', 'brand1@example.com', 'brand', 'Bio of brand1') | ||
| ON CONFLICT (username) DO NOTHING; | ||
| ``` |
There was a problem hiding this comment.
Current step order reintroduces duplicate-key failures during onboarding.
Step 3 seeds creator1/brand1, then Step 4 runs sql.txt, which inserts the same users without conflict handling. That can fail on unique constraints (username/email) and block setup.
Proposed doc fix
-3. **Create Required Tables**
+3. **Create Required Tables**
- Run the following SQL in the Supabase SQL Editor:
@@
- -- Seed Initial Data
- INSERT INTO public.users (username, email, role, bio)
- VALUES
- ('creator1', 'creator1@example.com', 'creator', 'Bio of creator1'),
- ('brand1', 'brand1@example.com', 'brand', 'Bio of brand1')
- ON CONFLICT (username) DO NOTHING;
+ -- Create schema only (no seed here)
@@
-4. **Run the SQL Script**
+4. **Run the SQL Script (initial data)**Alternative: keep Step 3 seed, but then sql.txt must also be made idempotent (ON CONFLICT on both unique keys strategy).
Also applies to: 218-221
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` around lines 210 - 215, The README currently seeds users in Step 3
and then runs sql.txt in Step 4 which re-inserts the same rows without conflict
handling; update the instructions so either Step 4 runs before Step 3 or
(preferably) modify sql.txt to make the INSERT into the users table idempotent
by adding ON CONFLICT handling for the unique keys (username and email) so
repeated runs won’t fail; reference the users table and its username/email
unique constraints and the files/steps named "Step 3", "Step 4", and "sql.txt"
when making the change.
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (1)
README.md (1)
209-209:⚠️ Potential issue | 🟡 MinorAdd DEFAULT to
last_seento match the backend model.The backend
Usermodel inBackend/app/models/models.pydefineslast_seenwithdefault=datetime.utcnow, but the documented schema omits the DEFAULT clause. This mismatch can cause inconsistency when the ORM creates records expecting a default timestamp.🔧 Proposed fix to align with backend model
- last_seen TIMESTAMP WITH TIME ZONE, + last_seen TIMESTAMP WITH TIME ZONE DEFAULT NOW(),🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@README.md` at line 209, The README schema is missing a DEFAULT for the last_seen column; update the CREATE TABLE/column definition for last_seen (referencing the User model's last_seen default=datetime.utcnow in Backend/app/models/models.py) to include a DEFAULT timestamp so the documented SQL matches the backend model (e.g., add a DEFAULT CURRENT_TIMESTAMP / equivalent to the last_seen TIMESTAMP WITH TIME ZONE definition).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@README.md`:
- Around line 195-196: Add a blank line immediately before the SQL fenced code
block (the ```sql fence) in the README so the fence is preceded by an empty line
per Markdown MD031; locate the section that currently reads "Run the following
SQL in the Supabase SQL Editor:" and insert a single blank line before the
opening ```sql fence to correct the formatting.
- Line 202: The README and DB use PostgreSQL native UUIDs but the ORM defines
id/foreign keys as Column(String, ...) with client-side uuid.uuid4(); update
models.py and chat.py to use SQLAlchemy's PostgreSQL UUID type (e.g.
UUID(as_uuid=True) from sqlalchemy.dialects.postgresql) for all primary key and
FK columns, remove client-side uuid.uuid4() defaults, and instead set
server_default to gen_random_uuid() (using sa.text or equivalent) so generation
and types match the documented schema; update any ForeignKey definitions to
reference UUID columns and ensure imports (UUID, sa.text) are added where
needed.
- Line 214: The ordered list item "4. **Run the SQL Script**" should use the
Markdown auto-numbering convention to satisfy MD029; update this list item (and
any other numbered list entries in the same sequence) to use "1." instead of
"4." so the renderer auto-numbers the steps and makes reordering easier while
keeping the visible text identical.
- Line 218: The README falsely claims the SQL initialization script includes
conflict handling; either update Backend/sql.txt to add ON CONFLICT clauses to
the INSERT statements for the unique fields (username, email) so the script
performs upserts, or edit README.md to remove/revise the sentence "The script
includes conflict handling to avoid duplicate entries" and reference that
upserts are handled only in the frontend (Onboarding.tsx) rather than in the
SQL; update whichever you choose and run a quick sanity check by re-running the
SQL to ensure repeated runs no longer error on unique constraint violations.
---
Duplicate comments:
In `@README.md`:
- Line 209: The README schema is missing a DEFAULT for the last_seen column;
update the CREATE TABLE/column definition for last_seen (referencing the User
model's last_seen default=datetime.utcnow in Backend/app/models/models.py) to
include a DEFAULT timestamp so the documented SQL matches the backend model
(e.g., add a DEFAULT CURRENT_TIMESTAMP / equivalent to the last_seen TIMESTAMP
WITH TIME ZONE definition).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: bc1a4b4f-cb33-4940-85f9-c42dcd8a9125
📒 Files selected for processing (1)
README.md
| - Run the following SQL in the Supabase SQL Editor: | ||
| ```sql |
There was a problem hiding this comment.
Add blank line before code fence for proper markdown formatting.
The fenced code block should be preceded by a blank line per markdown conventions.
📝 Proposed formatting fix
- Run the following SQL in the Supabase SQL Editor:
+
```sqlAs per static analysis hint: MD031 (blanks-around-fences).
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - Run the following SQL in the Supabase SQL Editor: | |
| ```sql | |
| - Run the following SQL in the Supabase SQL Editor: | |
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 196-196: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` around lines 195 - 196, Add a blank line immediately before the
SQL fenced code block (the ```sql fence) in the README so the fence is preceded
by an empty line per Markdown MD031; locate the section that currently reads
"Run the following SQL in the Supabase SQL Editor:" and insert a single blank
line before the opening ```sql fence to correct the formatting.
|
|
||
| -- Create Tables (Schema) | ||
| CREATE TABLE IF NOT EXISTS public.users ( | ||
| id UUID PRIMARY KEY DEFAULT gen_random_uuid(), |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check how the backend model interacts with the id column type
# Search for UUID type handling in models and database interactions
rg -n -C3 'Column\(String.*id|UUID|gen_random_uuid' Backend/app/models/
# Check if there are any explicit type casts or UUID handling
rg -n -C3 'uuid|UUID' Backend/app/ --type pyRepository: AOSSIE-Org/InPactAI
Length of output: 16595
🏁 Script executed:
# Check the README.md file around line 202 to see the schema documentation
sed -n '190,215p' README.md | cat -nRepository: AOSSIE-Org/InPactAI
Length of output: 1006
Align backend UUID type with documented PostgreSQL schema.
The README.md documents the database schema using PostgreSQL's native UUID type with gen_random_uuid() for the id column, but the backend SQLAlchemy models use Column(String, ...) with Python's uuid.uuid4() instead. This type mismatch between the documented schema (PostgreSQL UUID) and the ORM implementation (String) causes inconsistency in UUID generation (server-side vs client-side) and can lead to type coercion issues during queries and serialization. All id fields and foreign keys across models.py and chat.py need to use the same type as the actual database schema.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` at line 202, The README and DB use PostgreSQL native UUIDs but the
ORM defines id/foreign keys as Column(String, ...) with client-side
uuid.uuid4(); update models.py and chat.py to use SQLAlchemy's PostgreSQL UUID
type (e.g. UUID(as_uuid=True) from sqlalchemy.dialects.postgresql) for all
primary key and FK columns, remove client-side uuid.uuid4() defaults, and
instead set server_default to gen_random_uuid() (using sa.text or equivalent) so
generation and types match the documented schema; update any ForeignKey
definitions to reference UUID columns and ensure imports (UUID, sa.text) are
added where needed.
| ); | ||
| ``` | ||
|
|
||
| 4. **Run the SQL Script** |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider using "1." for all ordered list items (markdown convention).
Some markdown linters prefer using 1. for all ordered list items, letting the renderer handle auto-numbering. This improves maintainability when reordering steps.
📝 Optional formatting adjustment
-4. **Run the SQL Script**
+1. **Run the SQL Script**As per static analysis hint: MD029 (ol-prefix).
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 214-214: Ordered list item prefix
Expected: 1; Actual: 4; Style: 1/1/1
(MD029, ol-prefix)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` at line 214, The ordered list item "4. **Run the SQL Script**"
should use the Markdown auto-numbering convention to satisfy MD029; update this
list item (and any other numbered list entries in the same sequence) to use "1."
instead of "4." so the renderer auto-numbers the steps and makes reordering
easier while keeping the visible text identical.
| - Paste the queries into the SQL Editor and click **Run**. | ||
|
|
||
| This will populate the database with the required initial data for the platform. 🚀 | ||
| - The script includes conflict handling to avoid duplicate entries based on unique constraints. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check if sql.txt has ON CONFLICT handling
# Search for conflict handling in sql.txt
echo "=== Checking sql.txt for ON CONFLICT clauses ==="
rg -n 'ON CONFLICT' Backend/sql.txt || echo "No ON CONFLICT found in sql.txt"
# Show the INSERT statements in sql.txt
echo -e "\n=== INSERT statements in sql.txt ==="
rg -n -A5 'INSERT INTO' Backend/sql.txtRepository: AOSSIE-Org/InPactAI
Length of output: 5447
🏁 Script executed:
# Find schema-reference.md and check for conflict handling documentation
find . -name "schema-reference.md" -o -name "*schema*" -type f | head -20Repository: AOSSIE-Org/InPactAI
Length of output: 94
🏁 Script executed:
# Search for ON CONFLICT in the entire codebase
rg -i 'conflict|duplicate|unique' --type-list | head -5
rg -i 'on conflict' . 2>/dev/null || echo "No ON CONFLICT found in codebase"Repository: AOSSIE-Org/InPactAI
Length of output: 502
🏁 Script executed:
# Check if there's application-level handling for duplicates
rg -i 'duplicate|conflict handling' . --type md --type py --type js --type ts 2>/dev/null | head -30Repository: AOSSIE-Org/InPactAI
Length of output: 337
🏁 Script executed:
# Look at the full context around line 218 in README.md
sed -n '210,225p' README.mdRepository: AOSSIE-Org/InPactAI
Length of output: 488
🏁 Script executed:
# Check Onboarding.tsx to understand application-level duplicate handling
grep -A10 -B10 "Upsert to avoid duplicates" Frontend/src/components/Onboarding.tsxRepository: AOSSIE-Org/InPactAI
Length of output: 892
🏁 Script executed:
# Check if README.md has any other references to conflict handling or idempotency
grep -n -i "idempotent\|rerun\|duplicate\|constraint" README.mdRepository: AOSSIE-Org/InPactAI
Length of output: 165
🏁 Script executed:
# Verify the exact line 218 context and what follows
sed -n '214,222p' README.md | cat -nRepository: AOSSIE-Org/InPactAI
Length of output: 421
README.md incorrectly claims the SQL script includes conflict handling.
Line 218 states "The script includes conflict handling to avoid duplicate entries," but Backend/sql.txt contains bare INSERT statements without ON CONFLICT clauses. The queries will fail with unique constraint violations on username and email if run more than once, contradicting the documented behavior.
While the frontend includes application-level upsert logic (Onboarding.tsx), the README misleads users by claiming the SQL initialization script itself has conflict handling when it does not.
Either update sql.txt to add ON CONFLICT clauses to INSERT statements, or remove the false claim from the README documentation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` at line 218, The README falsely claims the SQL initialization
script includes conflict handling; either update Backend/sql.txt to add ON
CONFLICT clauses to the INSERT statements for the unique fields (username,
email) so the script performs upserts, or edit README.md to remove/revise the
sentence "The script includes conflict handling to avoid duplicate entries" and
reference that upserts are handled only in the frontend (Onboarding.tsx) rather
than in the SQL; update whichever you choose and run a quick sanity check by
re-running the SQL to ensure repeated runs no longer error on unique constraint
violations.
1 participant
Closes #285
📝 Description
Added SQL schema and seed data instructions to the README to prevent "relation does not exist" errors during initial setup.
This ensures that required tables are created before running the existing SQL script, improving onboarding for new contributors.
🔧 Changes Made
userstable📷 Screenshots or Visual Changes (if applicable)
N/A
🤝 Collaboration
Collaborated with: N/A
✅ Checklist
Summary by CodeRabbit