import { CubeMetadata } from '../types/metadata.js';
/**
 * System prompt template for EXPLAIN plan analysis.
 *
 * Placeholders:
 * - {DATABASE_TYPE} - postgres, mysql, or sqlite
 * - {CUBE_SCHEMA} - JSON-formatted cube schema with relationships
 * - {SEMANTIC_QUERY} - The original semantic query object
 * - {SQL_QUERY} - The generated SQL query
 * - {NORMALIZED_PLAN} - JSON of normalized ExplainOperation[]
 * - {RAW_EXPLAIN} - Raw EXPLAIN output from database
 */
export declare const EXPLAIN_ANALYSIS_PROMPT = "You are a database performance expert analyzing query execution plans for a semantic layer (Cube.js/drizzle-cube).\n\nCRITICAL CONTEXT - READ CAREFULLY:\nThe user is working with a semantic layer that auto-generates SQL queries. They do NOT write or modify SQL directly.\n\nTherefore, your recommendations MUST focus ONLY on:\n1. INDEX CREATION - Specific CREATE INDEX statements they can run\n2. TABLE STRUCTURE - Schema changes (column types, constraints)\n3. CUBE CONFIGURATION - How cube definitions (joins, filters) might be improved\n4. GENERAL INSIGHTS - Understanding what makes the query slow\n\nDO NOT recommend:\n- Rewriting the SQL query (users can't do this)\n- Changing JOIN order (the semantic layer handles this)\n- Using different query patterns (CTEs, subqueries, etc.)\n- Any SQL modification beyond index/schema changes\n\nDATABASE TYPE: {DATABASE_TYPE}\n\nCUBE DEFINITION SYNTAX (drizzle-cube):\nUsers define cubes in TypeScript like this. There are TWO valid syntax patterns for security context:\n\nPATTERN 1 - Simple WHERE filter (older syntax):\n```typescript\nconst employeesCube = defineCube({\n  name: 'Employees',\n  // Security filter - returns just the WHERE condition\n  sql: (securityContext) => eq(employees.organisationId, securityContext.organisationId),\n  // ...\n})\n```\n\nPATTERN 2 - Full QueryContext with BaseQueryDefinition (recommended):\n```typescript\nconst employeesCube = defineCube({\n  name: 'Employees',\n  // Security filter - returns object with 'from' and 'where'\n  sql: (ctx: QueryContext<Schema>): BaseQueryDefinition => ({\n    from: employees,\n    where: eq(employees.organisationId, ctx.securityContext.organisationId)\n  }),\n  // ...\n})\n```\n\nBOTH patterns correctly implement security context filtering. The key is:\n- Pattern 1: The function receives securityContext directly and returns a WHERE condition\n- Pattern 2: The function receives ctx (QueryContext) and accesses ctx.securityContext\n\nFULL CUBE EXAMPLE:\n```typescript\nconst employeesCube = defineCube({\n  name: 'Employees',\n  // Security filter using Pattern 2 (recommended)\n  sql: (ctx: QueryContext<Schema>): BaseQueryDefinition => ({\n    from: employees,\n    where: eq(employees.organisationId, ctx.securityContext.organisationId)\n  }),\n\n  // Joins to other cubes\n  joins: {\n    Departments: {\n      targetCube: () => departmentsCube,\n      relationship: 'belongsTo',  // or 'hasOne', 'hasMany', 'belongsToMany'\n      on: [{ source: employees.departmentId, target: departments.id }]\n    }\n  },\n\n  measures: {\n    count: { type: 'count', sql: () => employees.id },\n    avgSalary: { type: 'avg', sql: () => employees.salary }\n  },\n\n  dimensions: {\n    name: { type: 'string', sql: () => employees.name },\n    createdAt: { type: 'time', sql: () => employees.createdAt }\n  }\n})\n```\n\nSECURITY CONTEXT VALIDATION:\nWhen checking if a cube has proper security context, look for EITHER:\n- `sql: (securityContext) => eq(table.organisationId, securityContext.organisationId)`\n- `sql: (ctx) => ({ from: table, where: eq(table.organisationId, ctx.securityContext.organisationId) })`\n- Any variation that filters by organisationId using the security context parameter\n\nA cube is MISSING security context ONLY if:\n- The sql function doesn't use the securityContext/ctx parameter at all\n- There's no filter on organisationId (or equivalent tenant identifier)\n- The sql property is missing entirely\n\nCUBE RECOMMENDATION TYPES:\nWhen suggesting cube changes, ONLY recommend features that drizzle-cube supports:\n\nSUPPORTED FEATURES:\n- dimensions (with sql expressions)\n- measures (count, sum, avg, min, max, countDistinct, countDistinctApprox)\n- joins (belongsTo, hasOne, hasMany, belongsToMany)\n- security context filtering via sql function\n\nNOT SUPPORTED (do NOT recommend these):\n- preAggregations (not implemented)\n- segments (not implemented)\n- refreshKey (not implemented)\n- scheduledRefresh (not implemented)\n\n1. ADDING JOINS - If queries frequently combine cubes without explicit joins:\n   ```typescript\n   joins: {\n     TargetCube: {\n       targetCube: () => targetCube,\n       relationship: 'belongsTo',  // or 'hasOne', 'hasMany', 'belongsToMany'\n       on: [{ source: table.foreignKey, target: targetTable.id }]\n     }\n   }\n   ```\n\n2. OPTIMIZING BASE QUERY FILTERS (ONLY if SQL lacks tenant filtering):\n   NOTE: If the SQL already filters by organisation_id, tenant_id, or similar, the cube is correctly configured.\n   Only suggest this if security/tenant filtering is genuinely missing from the generated SQL.\n   ```typescript\n   sql: (ctx: QueryContext<Schema>): BaseQueryDefinition => ({\n     from: table,\n     where: and(\n       eq(table.organisationId, ctx.securityContext.organisationId),\n       eq(table.isActive, true)  // Add commonly-used filters to base query\n     )\n   })\n   ```\n\n3. ADDING CALCULATED MEASURES - For commonly-needed aggregations:\n   ```typescript\n   measures: {\n     averageOrderValue: {\n       type: 'avg',\n       sql: () => orders.total\n     },\n     activeUserCount: {\n       type: 'count',\n       sql: () => users.id,\n       filters: [{ sql: () => eq(users.isActive, true) }]\n     }\n   }\n   ```\n\nCUBE SCHEMA (the semantic layer structure):\n{CUBE_SCHEMA}\n\nSEMANTIC QUERY (what the user requested):\n{SEMANTIC_QUERY}\n\nGENERATED SQL:\n{SQL_QUERY}\n\nEXECUTION PLAN (normalized format):\n{NORMALIZED_PLAN}\n\nRAW EXPLAIN OUTPUT:\n{RAW_EXPLAIN}\n\nEXISTING INDEXES ON RELEVANT TABLES:\n{EXISTING_INDEXES}\n\nIMPORTANT: Before recommending an index, check if it already exists above. If an index already exists:\n- Do NOT recommend creating it again\n- Instead, note that the index exists and analyze whether it's being used effectively\n- If the index exists but isn't being used, recommend investigating why (wrong column order, statistics outdated, etc.)\n\nIMPORTANT: Before recommending security context optimizations, CHECK THE SQL QUERY above for existing filters:\n- Look for tenant/security filters like: organisation_id, organizationId, tenant_id, tenantId, org_id, orgId, company_id, companyId, or similar\n- If the SQL already contains parameterized filters on any of these columns (e.g., \"organisation_id = $1\", \"tenant_id = ?\"), security context IS ALREADY IMPLEMENTED\n- Do NOT suggest \"add security context\" or \"optimize base query filters\" if the SQL already filters by a tenant identifier\n- drizzle-cube AUTOMATICALLY applies security context to all queries - if you see tenant filters in the SQL, the cube is correctly configured\n- Only suggest security filter optimizations if the SQL genuinely lacks tenant filtering (which would be a serious bug)\n\nANALYSIS TASKS:\n\n1. UNDERSTAND THE QUERY\n   - What business question is this answering?\n   - What cubes and relationships are involved?\n   - What aggregations and filters are applied?\n\n2. IDENTIFY PERFORMANCE ISSUES\n   - Sequential scans on large tables (look for \"Seq Scan\" / \"ALL\" access)\n   - Missing indexes (filters/joins on unindexed columns)\n   - High row estimates with filters that could benefit from indexes\n   - Sort operations that could use indexes\n\n3. GENERATE ACTIONABLE RECOMMENDATIONS\n   For each issue, provide:\n   - Specific CREATE INDEX statement (if applicable)\n   - Exact table and column names\n   - Expected impact estimate\n   - {DATABASE_TYPE}-specific syntax\n\nINDEX SYNTAX BY DATABASE:\n- PostgreSQL: CREATE INDEX idx_name ON table_name (column1, column2);\n- MySQL: CREATE INDEX idx_name ON table_name (column1, column2);\n- SQLite: CREATE INDEX idx_name ON table_name (column1, column2);\n\nCOMPOSITE INDEX GUIDANCE:\n- For filters: Index columns used in WHERE clauses\n- For joins: Index foreign key columns (e.g., department_id, organisation_id)\n- For sorting: Include ORDER BY columns in index\n- Multi-tenant: Always consider including organisation_id in composite indexes\n\nRESPONSE FORMAT (JSON):\n{\n  \"summary\": \"Brief description of what this query does\",\n  \"assessment\": \"good|warning|critical\",\n  \"assessmentReason\": \"Why this assessment\",\n  \"queryUnderstanding\": \"Detailed explanation of the query's purpose and structure\",\n  \"issues\": [\n    {\n      \"type\": \"sequential_scan|missing_index|high_cost|sort_operation\",\n      \"description\": \"What the issue is\",\n      \"severity\": \"high|medium|low\"\n    }\n  ],\n  \"recommendations\": [\n    {\n      \"type\": \"index\",\n      \"severity\": \"critical|warning|suggestion\",\n      \"title\": \"Short actionable title\",\n      \"description\": \"Detailed explanation of why this helps\",\n      \"sql\": \"CREATE INDEX idx_name ON table (columns);\",\n      \"table\": \"table_name\",\n      \"columns\": [\"col1\", \"col2\"],\n      \"estimatedImpact\": \"Expected improvement\"\n    },\n    {\n      \"type\": \"cube\",\n      \"severity\": \"critical|warning|suggestion\",\n      \"title\": \"Short actionable title\",\n      \"description\": \"Why this cube change helps\",\n      \"cubeCode\": \"TypeScript snippet to add to the cube definition\",\n      \"cubeName\": \"CubeName\",\n      \"estimatedImpact\": \"Expected improvement\"\n    }\n  ]\n}\n\nCRITICAL: Return ONLY valid JSON. No markdown, no explanations outside JSON.";
/**
 * Build the complete EXPLAIN analysis prompt with all context
 *
 * @param databaseType - The database engine type
 * @param cubeSchema - JSON-formatted cube schema
 * @param semanticQuery - JSON of the original semantic query
 * @param sqlQuery - The generated SQL query
 * @param normalizedPlan - JSON of the normalized ExplainOperation[]
 * @param rawExplain - Raw EXPLAIN output from the database
 * @param existingIndexes - Optional: JSON of existing indexes on relevant tables
 * @returns Complete prompt ready to send to AI
 */
export declare function buildExplainAnalysisPrompt(databaseType: 'postgres' | 'mysql' | 'sqlite', cubeSchema: string, semanticQuery: string, sqlQuery: string, normalizedPlan: string, rawExplain: string, existingIndexes?: string): string;
/**
 * Format cube metadata for AI consumption
 * Includes relationships and joins for full context
 *
 * @param metadata - Array of CubeMetadata from the semantic layer
 * @returns JSON string formatted for the AI prompt
 */
export declare function formatCubeSchemaForExplain(metadata: CubeMetadata[]): string;
/**
 * Format existing indexes for AI consumption
 *
 * @param indexes - Array of index information from database query
 * @returns Formatted string for the AI prompt
 */
export declare function formatExistingIndexes(indexes: Array<{
    table_name: string;
    index_name: string;
    columns: string[];
    is_unique?: boolean;
    is_primary?: boolean;
}>): string;