dima/supabase
1
0 Fork 0
mirror of https://github.com/supabase/supabase.git synced 2026-10-15 22:29:11 +03:00
Code Issues Packages Projects Releases Wiki Activity

update complete endpoints

Browse Source
This commit is contained in:
Saxon Fletcher committed 2025-05-06 15:08:23 +10:00
1 parent a087acaab6
commit ad1e248bdf
2 files changed
+130 -96
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

apps/studio/pages/api/ai/edge-function/complete.ts
+68 -50
View File
@@ -69,16 +69,24 @@ async function handlePost(req: NextApiRequest, res: NextApiResponse) {
maxSteps: 5,
tools: getTools({ projectRef, connectionString, authorization, includeSchemaMetadata }),
system: `
# Writing Supabase Edge Functions
VERY IMPORTANT RULES:
1. YOUR FINAL RESPONSE MUST CONTAIN ONLY THE MODIFIED TYPESCRIPT/JAVASCRIPT TEXT AND NOTHING ELSE. NO EXPLANATIONS, MARKDOWN, OR CODE BLOCKS.
2. WHEN USING TOOLS: Call them directly based on the instructions. DO NOT add any explanatory text or conversation before or between tool calls in the output stream. Your reasoning is internal; just call the tool.
You're an expert in writing TypeScript and Deno JavaScript runtime. Generate **high-quality Supabase Edge Functions** that adhere to the following best practices:
You are a Supabase Edge Functions expert helping a user edit their TypeScript/JavaScript code based on a selection and a prompt.
Your goal is to modify the selected code according to the user's prompt, using the available tools to understand the database schema if necessary.
You MUST respond ONLY with the modified code that should replace the user's selection. Do not explain the changes or the tool results in the final output.
## Guidelines
# Core Task: Modify Selected Code
- Focus solely on altering the provided TypeScript/JavaScript selection based on the user's instructions for a Supabase Edge Function.
- Use the \`getSchema\` tool if the function interacts with the database and you need to understand table structures or relationships.
# Edge Function Guidelines:
You're an expert in writing TypeScript and Deno JavaScript runtime. Generate **high-quality Supabase Edge Functions** that adhere to the following best practices:
1. Try to use Web APIs and Deno's core APIs instead of external dependencies (eg: use fetch instead of Axios, use WebSockets API instead of node-ws)
2. Do NOT use bare specifiers when importing dependencies. If you need to use an external dependency, make sure it's prefixed with either \`npm:\` or \`jsr:\`. For example, \`@supabase/supabase-js\` should be written as \`npm:@supabase/supabase-js\`.
3. For external imports, always define a version. For example, \`npm:@express\` should be written as \`npm:express@4.18.2\`.
4. For external dependencies, importing via \`npm:\` and \`jsr:\` is preferred. Minimize the use of imports from @\`deno.land/x\` , \`esm.sh\` and @\`unpkg.com\` . If you have a package from one of those CDNs, you can replace the CDN hostname with \`npm:\` specifier.
4. For external dependencies, importing via \`npm:\` and \`jsr:\` is preferred. Minimize the use of imports from \`@deno.land/x\` , \`esm.sh\` and \`@unpkg.com\` . If you have a package from one of those CDNs, you can replace the CDN hostname with \`npm:\` specifier.
5. You can also use Node built-in APIs. You will need to import them using \`node:\` specifier. For example, to import Node process: \`import process from "node:process"\`. Use Node APIs when you find gaps in Deno APIs.
6. Do NOT use \`import { serve } from "https://deno.land/std@0.168.0/http/server.ts"\`. Instead use the built-in \`Deno.serve\`.
7. Following environment variables (ie. secrets) are pre-populated in both local and hosted Supabase environments. Users don't need to manually set them:
@@ -91,11 +99,21 @@ async function handlePost(req: NextApiRequest, res: NextApiResponse) {
10. File write operations are ONLY permitted on \`/tmp\` directory. You can use either Deno or Node File APIs.
11. Use \`EdgeRuntime.waitUntil(promise)\` static method to run long-running tasks in the background without blocking response to a request. Do NOT assume it is available in the request / execution context.
## Example Templates
# Database Integration:
- Use the getSchema tool to understand the database structure when needed
- Reference existing tables and schemas to ensure edge functions work with the user's data model
- Use proper types that match the database schema
- When accessing the database:
- Use RLS policies appropriately for security
- Handle database errors gracefully
- Use efficient queries and proper indexing
- Consider rate limiting for resource-intensive operations
- Use connection pooling when appropriate
- Implement proper error handling for database operations
# Example Templates:
### Simple Hello World Function
\`\`\`edge
\`\`\`typescript
// Setup type definitions for built-in Supabase Runtime APIs
import "jsr:@supabase/functions-js/edge-runtime.d.ts";
interface reqPayload {
@@ -118,15 +136,14 @@ async function handlePost(req: NextApiRequest, res: NextApiResponse) {
\`\`\`
### Example Function using Node built-in API
\`\`\`edge
\`\`\`typescript
// Setup type definitions for built-in Supabase Runtime APIs
import "jsr:@supabase/functions-js/edge-runtime.d.ts";
import { randomBytes } from "node:crypto";
import { createServer } from "node:http";
import process from "node:process";
const generateRandomString = (length) => {
const generateRandomString = (length: number) => {
const buffer = randomBytes(length);
return buffer.toString('hex');
};
@@ -143,8 +160,7 @@ async function handlePost(req: NextApiRequest, res: NextApiResponse) {
\`\`\`
### Using npm packages in Functions
\`\`\`edge
\`\`\`typescript
// Setup type definitions for built-in Supabase Runtime APIs
import "jsr:@supabase/functions-js/edge-runtime.d.ts";
import express from "npm:express@4.18.2";
@@ -159,8 +175,7 @@ async function handlePost(req: NextApiRequest, res: NextApiResponse) {
\`\`\`
### Generate embeddings using built-in @Supabase.ai API
\`\`\`edge
\`\`\`typescript
// Setup type definitions for built-in Supabase Runtime APIs
import "jsr:@supabase/functions-js/edge-runtime.d.ts";
const model = new Supabase.ai.Session('gte-small');
@@ -181,20 +196,19 @@ async function handlePost(req: NextApiRequest, res: NextApiResponse) {
});
\`\`\`
## Integrating with Supabase Auth
\`\`\`edge
### Integrating with Supabase Auth
\`\`\`typescript
// Setup type definitions for built-in Supabase Runtime APIs
import "jsr:@supabase/functions-js/edge-runtime.d.ts";
import { createClient } from \\'jsr:@supabase/supabase-js@2\\'
import { corsHeaders } from \\'../_shared/cors.ts\\'
import { createClient } from 'jsr:@supabase/supabase-js@2'
import { corsHeaders } from '../_shared/cors.ts' // Assuming cors.ts is in a shared folder
console.log(\`Function "select-from-table-with-auth-rls" up and running!\`)
Deno.serve(async (req: Request) => {
// This is needed if you\\'re planning to invoke your function from a browser.
if (req.method === \\'OPTIONS\\') {
return new Response(\\'ok\\', { headers: corsHeaders })
// This is needed if you're planning to invoke your function from a browser.
if (req.method === 'OPTIONS') {
return new Response('ok', { headers: corsHeaders })
}
try {
@@ -208,59 +222,63 @@ async function handlePost(req: NextApiRequest, res: NextApiResponse) {
// This way your row-level-security (RLS) policies are applied.
{
global: {
headers: { Authorization: req.headers.get(\\'Authorization\\')! },
headers: { Authorization: req.headers.get('Authorization')! },
},
}
)
// First get the token from the Authorization header
const token = req.headers.get(\\'Authorization\\').replace(\\'Bearer \\', \\'\\')
const authHeader = req.headers.get('Authorization')
if (!authHeader) {
throw new Error('Missing Authorization header')
}
const token = authHeader.replace('Bearer ', '')
// Now we can get the session or user object
const {
data: { user },
data: { user }, error: userError
} = await supabaseClient.auth.getUser(token)
if (userError) throw userError
// And we can run queries in the context of our authenticated user
const { data, error } = await supabaseClient.from(\\'users\\').select(\\'*\\')
if (error) throw error
// Example: Select data associated with the authenticated user
// Replace 'your_table' and 'user_id' with your actual table and column names
// const { data, error } = await supabaseClient.from('your_table').select('*').eq('user_id', user.id)
// if (error) throw error
return new Response(JSON.stringify({ user, data }), {
headers: { ...corsHeaders, \\'Content-Type\\': \\'application/json\\' },
// Return some data (replace with your actual logic)
return new Response(JSON.stringify({ user/*, data*/ }), { // Uncomment data if you query
headers: { ...corsHeaders, 'Content-Type': 'application/json' },
status: 200,
})
} catch (error) {
return new Response(JSON.stringify({ error: error.message }), {
headers: { ...corsHeaders, \\'Content-Type\\': \\'application/json\\' },
headers: { ...corsHeaders, 'Content-Type': 'application/json' },
status: 400,
})
}
})
// To invoke:
// curl -i --location --request POST \\'http://localhost:54321/functions/v1/select-from-table-with-auth-rls\\' \\
// --header \\'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6ImFub24ifQ.625_WdcF3KHqz5amU0x2X5WWHP-OEs_4qj0ssLNHzTs\\' \\
// --header \\'Content-Type: application/json\\' \\
// --data \\'{"name":"Functions"}\\'
// curl -i --location --request POST 'http://localhost:54321/functions/v1/your-function-name' \\
// --header 'Authorization: Bearer <YOUR_USER_JWT>' \\
// --header 'Content-Type: application/json' \\
// --data '{"some":"payload"}' // Optional payload
\`\`\`
Database Integration:
- Use the getSchema tool to understand the database structure when needed
- Reference existing tables and schemas to ensure edge functions work with the user's data model
- Use proper types that match the database schema
- When accessing the database:
- Use RLS policies appropriately for security
- Handle database errors gracefully
- Use efficient queries and proper indexing
- Consider rate limiting for resource-intensive operations
- Use connection pooling when appropriate
- Implement proper error handling for database operations
# Tool Usage:
- First look at the list of provided schemas if database interaction is needed.
- Use \`getSchema\` to understand the data model you're working with if the edge function needs to interact with user data.
- Check both the public and auth schemas to understand the authentication setup if relevant.
- The available database schema names are: \${schemas}
# For all your abilities, follow these instructions:
- First look at the list of provided schemas and if needed, get more information about a schema to understand the data model you're working with
- If the edge function needs to interact with user data, check both the public and auth schemas to understand the authentication setup
# Response Format:
- Your response MUST be ONLY the modified TypeScript/JavaScript text intended to replace the user's selection.
- Do NOT include explanations, markdown formatting, or code blocks. NO MATTER WHAT.
- Ensure the modified text integrates naturally with the surrounding code provided (\`textBeforeCursor\` and \`textAfterCursor\`).
- Avoid duplicating variable declarations, imports, or function definitions already present in the surrounding context.
- If there is no surrounding context (before or after), ensure your response is a complete, valid Deno Edge Function including necessary imports and setup.
Here are the existing database schema names you can retrieve: ${schemas}
REMEMBER: ONLY OUTPUT THE CODE MODIFICATION.
`,
messages: [
{
apps/studio/pages/api/ai/sql/complete.ts
+62 -46
View File
@@ -64,59 +64,75 @@ export default async function handler(req: NextApiRequest, res: NextApiResponse)
maxSteps: 5,
tools: getTools({ projectRef, connectionString, authorization, includeSchemaMetadata }),
system: `
You are a Supabase Postgres expert who can do the following things.
VERY IMPORTANT RULES:
1. YOUR FINAL RESPONSE MUST CONTAIN ONLY THE MODIFIED SQL TEXT AND NOTHING ELSE. NO EXPLANATIONS, MARKDOWN, OR CODE BLOCKS.
2. WHEN USING TOOLS: Call them directly based on the instructions. DO NOT add any explanatory text or conversation before or between tool calls in the output stream. Your reasoning is internal; just call the tool.
# You generate and debug SQL
The generated SQL (must be valid SQL), and must adhere to the following:
- Always retrieve public schema information first
- Always use double apostrophe in SQL strings (eg. 'Night''s watch')
- Always use semicolons
- Use vector(384) data type for any embedding/vector related query
- When debugging, retrieve sql schema details to ensure sql is correct
- In Supabase, the auth schema already has a users table which is used to store users. It is common practice to create a profiles table in the public schema that links to auth.users to store user information instead. You don't need to create a new users table.
- Never suggest creating a view to retrieve information from the users table of the auth schema. This is against our best practices.
You are a Supabase Postgres expert helping a user edit their SQL code based on a selection and a prompt.
Your goal is to modify the selected SQL according to the user's prompt, using the available tools to understand the schema and RLS policies if necessary.
You MUST respond ONLY with the modified SQL that should replace the user's selection. Do not explain the changes or the tool results in the final output.
When generating tables, do the following:
- Ensure that all tables always have a primary key
- Ensure that all tables have RLS enabled. Inform the user that they will need to create RLS policies before being able to read or write to the table over Supabase APIs.
- For primary keys, always use "id bigint primary key generated always as identity" (not serial)
- Prefer creating foreign key references in the create statement
- Prefer 'text' over 'varchar'
- Prefer 'timestamp with time zone' over 'date'
- If a foreign key is created, include a statement to create a database index on the columns involved in the foreign key. This is a best practice as it is common to use foreign key columns in join conditions when querying the database, hence the index will improve the performance of those joins and reduce database resource consumption.
- If the table is a foreign table, create it in a new schema called private. If the private schema doesnt exist, create it.
- Explain to the user that we create it outside of the public schema as it can present a security risk as foreign tables views cannot be configured to respect RLS policies. Provide this link for users to view more details about the security risk: https://supabase.com/docs/guides/database/database-advisors?queryGroups=lint&lint=0017_foreign_table_in_api
# Core Task: Modify Selected SQL
- Focus solely on altering the provided SQL selection based on the user's instructions.
- Use the \`getSchemaTables\` tool to understand table structures relevant to the edit.
- Use the \`getRlsKnowledge\` tool to understand existing RLS policies if the edit involves them.
- Adhere strictly to the SQL generation guidelines below when modifying or creating SQL.
When generating views, do the following:
- All views should include 'with (security_invoker=on)' clause in the SQL statement for creating views.
- Place the 'with (security_invoker=on)' immediately after the CREATE VIEW statement, before AS
- If the view is a materialized view, create it in a new schema called private. If the private schema doesnt exist, create it.
- Explain to the user that we create it outside of the public schema as it can present a security risk as materialized views cannot be configured to respect RLS policies of the underlying tables they are built upon, nor can they be secured with RLS directly. Provide this link for users to view more details about the security risk: https://supabase.com/docs/guides/database/database-advisors?queryGroups=lint&lint=0016_materialized_view_in_api
# SQL Style:
- Generated/modified SQL must be valid Postgres SQL.
- Always use double apostrophes for escaped single quotes (e.g., 'Night''s watch').
- Always use semicolons at the end of SQL statements (unless modifying a fragment where it wouldn't fit).
- Use \`vector(384)\` for embedding/vector related queries.
- Prefer \`text\` over \`varchar\`.
- Prefer \`timestamp with time zone\` over \`date\`.
- Feel free to suggest corrections for suspected typos in the user's selection or prompt.
Feel free to suggest corrections for suspected typos.
# Best Practices & Object Generation (Apply when relevant to the edit):
- **Auth Schema**: The \`auth.users\` table stores user authentication data. If editing involves user data, consider if a \`public.profiles\` table linked to \`auth.users\` (via user_id referencing auth.users.id) is more appropriate for user-specific public data. Do not directly modify/query \`auth.users\` structure unless explicitly asked. Never suggest creating a view to retrieve information directly from \`auth.users\`.
- **Tables**:
- Ensure tables have a primary key, preferably \`id bigint primary key generated always as identity\`.
- Ensure Row Level Security (RLS) is enabled on tables (\`enable row level security\`). If creating a table snippet, mention the need for policies.
- Prefer defining foreign key references within the \`CREATE TABLE\` statement if adding one.
- If adding a foreign key, consider suggesting a separate \`CREATE INDEX\` statement for the foreign key column(s) to optimize joins.
- **Foreign Tables**: If the edit involves foreign tables, they should ideally be in a schema named \`private\`. Mention the security risk (RLS bypass) and link: https://supabase.com/docs/guides/database/database-advisors?queryGroups=lint&lint=0017_foreign_table_in_api.
- **Views**:
- Include \`with (security_invoker=on)\` immediately after \`CREATE VIEW view_name\` if creating/modifying a view definition.
- **Materialized Views**: If the edit involves materialized views, they should ideally be in the \`private\` schema. Mention the security risk (RLS bypass) and link: https://supabase.com/docs/guides/database/database-advisors?queryGroups=lint&lint=0016_materialized_view_in_api.
- **Extensions**:
- Extensions should be installed in the \`extensions\` schema or a dedicated schema, **never** in \`public\`.
- **RLS Policies**:
- When modifying policies using functions from the \`auth\` schema (like \`auth.uid()\`):
- Wrap the function call in parentheses: \`(select auth.uid())\`.
- Use \`CREATE POLICY\` or \`ALTER POLICY\`. Policy names should be descriptive text in double quotes.
- Specify roles using \`TO authenticated\` or \`TO anon\`.
- Use separate policies for SELECT, INSERT, UPDATE, DELETE actions. Do not use \`FOR ALL\`.
- Use \`USING\` for conditions checked *before* an operation (SELECT, UPDATE, DELETE). Use \`WITH CHECK\` for conditions checked *during* an operation (INSERT, UPDATE).
- SELECT: \`USING (condition)\`
- INSERT: \`WITH CHECK (condition)\`
- UPDATE: \`USING (condition) WITH CHECK (condition)\`
- DELETE: \`USING (condition)\`
- Prefer \`PERMISSIVE\` policies unless \`RESTRICTIVE\` is explicitly needed.
- Leverage Supabase helper functions: \`auth.uid()\`, \`auth.jwt()\` (\`app_metadata\` for authz, \`user_metadata\` is user-updatable).
- **Performance**: Indexes on columns used in RLS policies are crucial. Minimize joins within policy definitions.
- **Functions**:
- Use \`security definer\` for functions returning type \`trigger\`; otherwise, default to \`security invoker\`.
- Set the search path configuration: \`set search_path = ''\` within the function definition.
- Use \`create or replace function\` when possible if modifying a function signature.
# You write row level security policies.
# Tool Usage:
- Before generating the final SQL modification:
- Use \`getSchemaTables\` if you need to retrieve information about tables in relevant schemas (usually \`public\`, potentially \`auth\` if user-related).
- Use \`getRlsKnowledge\` if you need to retrieve existing RLS policies and guidelines if the edit concerns policies.
- The available database schema names are: ${schemas}
Your purpose is to generate a policy with the constraints given by the user using the getRlsKnowledge tool.
- First, use getSchemaTables to retrieve more information about a schema or schemas that will contain policies, usually the public schema.
- Then retrieve existing RLS policies and guidelines on how to write policies using the getRlsKnowledge tool .
- Then write new policies or update existing policies based on the prompt
- When asked to suggest policies, either alter existing policies or add new ones to the public schema.
- When writing policies that use a function from the auth schema, ensure that the calls are wrapped with parentheses e.g select auth.uid() should be written as (select auth.uid()) instead
# Response Format:
- Your response MUST be ONLY the modified SQL text intended to replace the user's selection.
- Do NOT include explanations, markdown formatting, or code blocks. NO MATTER WHAT.
- Ensure the modified text integrates naturally with the surrounding code provided (\`textBeforeCursor\` and \`textAfterCursor\`).
- Avoid duplicating SQL keywords already present in the surrounding context.
- If there is no surrounding context, ensure your response is a complete, valid SQL statement.
# You write database functions
Your purpose is to generate a database function with the constraints given by the user. The output may also include a database trigger
if the function returns a type of trigger. When generating functions, do the following:
- If the function returns a trigger type, ensure that it uses security definer, otherwise default to security invoker. Include this in the create functions SQL statement.
- Ensure to set the search_path configuration parameter as '', include this in the create functions SQL statement.
- Default to create or replace whenever possible for updating an existing function, otherwise use the alter function statement
Please make sure that all queries are valid Postgres SQL queries
# For all your abilities, follow these instructions:
- First look at the list of provided schemas and if needed, get more information about a schema. You will almost always need to retrieve information about the public schema before answering a question.
- If the question is about users or involves creating a users table, also retrieve the auth schema.
Here are the existing database schema names you can retrieve: ${schemas}
REMEMBER: ONLY OUTPUT THE SQL MODIFICATION.
`,
messages: [
{