Supabase Database - MyGGV GPS

Objectif

Gérer la base de données Supabase du projet MyGGV GPS : locations (blocs), POIs, et données de navigation.

Périmètre

Inclus

• •Exécution de requêtes SQL (execute_sql)
• •Création et application de migrations (apply_migration)
• •Listing des tables et extensions
• •Vérification des advisors (sécurité, performance)
• •Consultation des logs
• •Génération des types TypeScript

Exclus

• •Documentation Supabase → utiliser archon-project
• •Déploiement → utiliser netlify-deploy

Tables du Projet

locations

Table principale contenant les blocs du village :

• •id : UUID
• •name : Nom du bloc (ex: "Block 1", "Block 2A")
• •coords : Coordonnées du polygone (JSONB)
• •color : Couleur d'affichage
• •created_at : Timestamp

public_pois

Points d'intérêt publics :

• •id : UUID
• •name : Nom du POI
• •type : Type (school, church, pool, etc.)
• •coordinates : [lng, lat]

Workflow Type

Vérifier l'état de la base

1. mcp__supabase__list_tables() - Lister les tables
2. mcp__supabase__get_advisors({ type: "security" }) - Vérifier RLS
3. mcp__supabase__get_advisors({ type: "performance" }) - Optimisations

Créer une migration

1. Analyser le besoin
2. mcp__supabase__apply_migration({
     name: "add_poi_category",
     query: "ALTER TABLE public_pois ADD COLUMN category TEXT;"
   })
3. Vérifier avec execute_sql

Requête de données

mcp__supabase__execute_sql({
  query: "SELECT * FROM locations WHERE name LIKE 'Block%' LIMIT 10;"
})

Bonnes Pratiques

1. •Toujours vérifier les advisors après une migration DDL
2. •Utiliser des noms snake_case pour les migrations
3. •Ne jamais hardcoder d'IDs dans les migrations de données
4. •Vérifier RLS sur toutes les tables publiques

Variables d'Environnement

Le projet utilise :

• •VITE_SUPABASE_URL - URL du projet Supabase
• •VITE_SUPABASE_ANON_KEY - Clé publique (anon)

Ces variables sont configurées dans .env et sur Netlify.