Supabase Configuration Guide for MelodyMaker
This guide provides detailed instructions for configuring Supabase for the Melody-
Maker project, including setting up necessary database tables, configuring Row
Level Security (RLS) policies, and testing the configuration.
Connection Details
VITE_SUPABASE_URL=https://sioiojtcvpcidzumlqcb.supabase.co
VITE_SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6
1. Accessing the Supabase Dashboard
1. Navigate to https://app.supabase.com/ in your web browser
2. Sign in with your Supabase account credentials
3. From the dashboard, select the MelodyMaker project
4. You’ll be directed to the project dashboard where you can manage your
database, authentication, storage, and other features
2. Creating Tables for MelodyMaker
The MelodyMaker project requires four main tables: events, venues, sources,
and jobs. Below are the SQL commands to create each table with appropriate
columns and constraints.
Table: venues
CREATE TABLE venues (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
name TEXT NOT NULL,
address TEXT,
city TEXT,
state TEXT,
country TEXT,
postal_code TEXT,
latitude NUMERIC,
longitude NUMERIC,
website TEXT,
phone TEXT,
email TEXT,
capacity INTEGER,
description TEXT,
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
1
-- Create an index on the name column for faster searches
CREATE INDEX idx_venues_name ON venues (name);
Table: sources
CREATE TABLE sources (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
name TEXT NOT NULL,
url TEXT,
description TEXT,
type TEXT,
active BOOLEAN DEFAULT TRUE,
last_scraped_at TIMESTAMP WITH TIME ZONE,
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
-- Create an index on the name column for faster searches
CREATE INDEX idx_sources_name ON sources (name);
Table: events
CREATE TABLE events (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
title TEXT NOT NULL,
description TEXT,
start_time TIMESTAMP WITH TIME ZONE NOT NULL,
end_time TIMESTAMP WITH TIME ZONE,
venue_id UUID REFERENCES venues(id),
source_id UUID REFERENCES sources(id),
external_id TEXT,
url TEXT,
image_url TEXT,
ticket_url TEXT,
price_range TEXT,
genre TEXT[],
artists TEXT[],
tags TEXT[],
status TEXT DEFAULT 'active',
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
-- Create indexes for common query patterns
CREATE INDEX idx_events_start_time ON events (start_time);
CREATE INDEX idx_events_venue_id ON events (venue_id);
2
CREATE INDEX idx_events_source_id ON events (source_id);
CREATE INDEX idx_events_status ON events (status);
Table: jobs
CREATE TABLE jobs (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
type TEXT NOT NULL,
status TEXT NOT NULL DEFAULT 'pending',
source_id UUID REFERENCES sources(id),
params JSONB,
result JSONB,
error TEXT,
started_at TIMESTAMP WITH TIME ZONE,
completed_at TIMESTAMP WITH TIME ZONE,
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
-- Create indexes for common query patterns
CREATE INDEX idx_jobs_type ON jobs (type);
CREATE INDEX idx_jobs_status ON jobs (status);
CREATE INDEX idx_jobs_source_id ON jobs (source_id);
How to Create Tables
1. In the Supabase dashboard, navigate to the Table Editor in the left
sidebar
2. Click on New Table to create each table manually, or
3. Use the SQL Editor to run the SQL commands above:
• Click on SQL Editor in the left sidebar
• Create a new query
• Paste the SQL commands for each table
• Click Run to execute the commands
3. Setting Up Row Level Security (RLS) Policies
Row Level Security (RLS) allows you to control which users can access which
rows in your database tables. By default, RLS is enabled on Supabase tables,
which means no access is granted until you define policies.
Enable RLS on All Tables
First, ensure RLS is enabled on all tables:
1. Go to the Authentication section in the left sidebar
2. Click on Policies
3
3. For each table, make sure the RLS toggle is set to ON
Create RLS Policies for Each Table
Venues Table Policies
-- Allow anonymous and authenticated users to read venues
CREATE POLICY "Venues are viewable by everyone"
ON venues FOR SELECT
USING (true);
-- Allow only authenticated users to insert venues
CREATE POLICY "Authenticated users can insert venues"
ON venues FOR INSERT
TO authenticated
USING (true);
-- Allow only authenticated users to update their own venues
CREATE POLICY "Authenticated users can update their own venues"
ON venues FOR UPDATE
TO authenticated
USING (auth.uid() = created_by);
Sources Table Policies
-- Allow anonymous and authenticated users to read sources
CREATE POLICY "Sources are viewable by everyone"
ON sources FOR SELECT
USING (true);
-- Allow only authenticated users to insert sources
CREATE POLICY "Authenticated users can insert sources"
ON sources FOR INSERT
TO authenticated
USING (true);
-- Allow only authenticated users to update their own sources
CREATE POLICY "Authenticated users can update their own sources"
ON sources FOR UPDATE
TO authenticated
USING (auth.uid() = created_by);
Events Table Policies
-- Allow anonymous and authenticated users to read events
CREATE POLICY "Events are viewable by everyone"
ON events FOR SELECT
4
USING (true);
-- Allow only authenticated users to insert events
CREATE POLICY "Authenticated users can insert events"
ON events FOR INSERT
TO authenticated
USING (true);
-- Allow only authenticated users to update their own events
CREATE POLICY "Authenticated users can update their own events"
ON events FOR UPDATE
TO authenticated
USING (auth.uid() = created_by);
Jobs Table Policies
-- Allow only authenticated users to read jobs
CREATE POLICY "Only authenticated users can view jobs"
ON jobs FOR SELECT
TO authenticated
USING (true);
-- Allow only authenticated users to insert jobs
CREATE POLICY "Only authenticated users can insert jobs"
ON jobs FOR INSERT
TO authenticated
USING (true);
-- Allow only authenticated users to update their own jobs
CREATE POLICY "Only authenticated users can update their own jobs"
ON jobs FOR UPDATE
TO authenticated
USING (auth.uid() = created_by);
How to Apply RLS Policies
1. In the Supabase dashboard, navigate to the Authentication section
2. Click on Policies
3. Select the table you want to add policies to
4. Click on New Policy
5. You can either:
• Use the policy generator to create policies through the UI
• Click on Custom Policy to write your own SQL policy
6. For the custom policy option, paste the SQL commands above
7. Click Save to apply the policy
5
4. Testing the Configuration
After setting up the tables and RLS policies, it’s important to test that everything
works as expected.
Testing with the Supabase UI
1. Go to the Table Editor in the Supabase dashboard
2. Try to insert, select, update, and delete records in each table
3. Test both when logged in as an administrator and when using the anony-
mous key
Testing with the API
You can test the API access using cURL or any HTTP client:
Anonymous Access Test (Read-only)
# Test reading venues (should succeed)
curl -X GET "https://sioiojtcvpcidzumlqcb.supabase.co/rest/v1/venues?select=*" \
-H "apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InNpb2lva
# Test inserting a venue (should fail for anonymous users)
curl -X POST "https://sioiojtcvpcidzumlqcb.supabase.co/rest/v1/venues" \
-H "apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InNpb2lva
-H "Content-Type: application/json" \
-d '{"name": "Test Venue", "city": "Test City"}'
Authenticated Access Test To test authenticated access, you’ll need to:
1. Create a test user in the Authentication section of the Supabase dash-
board
2. Generate a session token for that user
3. Use that token in your API requests:
# Test inserting a venue as an authenticated user (should succeed)
curl -X POST "https://sioiojtcvpcidzumlqcb.supabase.co/rest/v1/venues" \
-H "apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InNpb2lva
-H "Authorization: Bearer YOUR_USER_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name": "Test Venue", "city": "Test City"}'
Testing with JavaScript Client
You can also test using the Supabase JavaScript client:
import { createClient } from '@supabase/supabase-js'
const supabaseUrl = 'https://sioiojtcvpcidzumlqcb.supabase.co'
6
const supabaseAnonKey = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZi
const supabase = createClient(supabaseUrl, supabaseAnonKey)
// Test reading venues (should succeed for anonymous users)
const { data, error } = await supabase
.from('venues')
.select('*')
.limit(5)
console.log('Read result:', data, error)
// Test inserting a venue (should fail for anonymous users)
const { data: insertData, error: insertError } = await supabase
.from('venues')
.insert([
{ name: 'Test Venue', city: 'Test City' }
])
console.log('Insert result:', insertData, insertError)
// To test as an authenticated user, first sign in:
const { user, session, error: authError } = await supabase.auth.signIn({
email: 'test@example.com',
password: 'password123'
})
// Then try the insert again (should succeed)
const { data: authInsertData, error: authInsertError } = await supabase
.from('venues')
.insert([
{ name: 'Auth Test Venue', city: 'Auth Test City' }
])
console.log('Authenticated insert result:', authInsertData, authInsertError)
Troubleshooting Common Issues
RLS Policy Issues
If you’re experiencing unexpected permission denials:
1. Check that your RLS policies are correctly defined
2. Verify that the user has the correct role (anonymous vs. authenticated)
3. For authenticated users, ensure the JWT token is valid and not expired
4. Check the Supabase logs for any error messages
7
Database Schema Issues
If you encounter issues with the database schema:
1. Verify that all tables have been created with the correct columns and
constraints
2. Check for any foreign key constraints that might be preventing operations
3. Ensure that indexes are created for columns that are frequently queried
Conclusion
This guide has walked you through the process of configuring Supabase for the
MelodyMaker project, including creating the necessary tables, setting up RLS
policies, and testing the configuration. By following these steps, you should have
a fully functional Supabase backend that securely manages access to your data.
Remember to regularly review and update your RLS policies as your application’s
requirements evolve to maintain proper security.
