mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 17:35:10 +03:00
## What kind of change does this PR introduce? Feature polish and a connection behaviour change. ## What is the current behaviour? The Warehouse Connect sheet presents FlightSQL and DuckDB configuration together. Enabling Warehouse also enables DuckDB catalogue access automatically, even when the user only needs FlightSQL. ## What is the new behaviour? The Connect sheet now starts with a query engine selector: - FlightSQL shows the endpoint, connection string, user, password action, and command-line example. - DuckDB shows a persistent catalogue access switch. When enabled, credentials and the attach script appear as the same numbered "Follow these steps" flow used by other connection methods. - Switching back to FlightSQL removes the DuckDB instructions. > [!NOTE] > This is an incremental change towards [this UI](https://linear.app/supabase/project/warehouse-core-mvp-b85711dc2eff/activity#project-update-4e3183e1), where the Integrations page is the control plane and Connect sheet is simply for read-only connect values. https://github.com/supabase/supabase/pull/50247 and https://github.com/supabase/supabase/pull/50195 are subsequent PRs that get us there. > [!IMPORTANT] > Enabling Warehouse no longer enables DuckDB catalogue access automatically. DuckDB users must enable it explicitly from the connection details. FlightSQL is unaffected. This keeps global Warehouse provisioning separate from optional credentials for one query engine. It also prevents successful Warehouse setup from being followed by a secondary catalogue mutation that can fail independently. | Before | After | | --- | --- | | <img width="1280" height="1323" alt="10752" src="https://github.com/user-attachments/assets/83b1069b-a262-4068-a5e3-b7f49860fdb2" /> | <img width="1280" height="1323" alt="Regular AWS Teamer Supabase" src="https://github.com/user-attachments/assets/86ff1fe4-6513-44a8-88e1-1c7985f4910e" /> | | <img width="1280" height="1323" alt="10752" src="https://github.com/user-attachments/assets/83b1069b-a262-4068-a5e3-b7f49860fdb2" /> | <img width="1280" height="1323" alt="31254" src="https://github.com/user-attachments/assets/733f074d-a52a-44a6-8898-a8f3c2b68294" /> | | _Unable to replicate._ | <img width="1280" height="1323" alt="Regular AWS Teamer Supabase" src="https://github.com/user-attachments/assets/c7d4ee59-b3f0-48b0-a6d7-2202ef5c2609" /> | ## To test 1. Open `/project/{ref}?showConnect=true&connectTab=warehouse` on a project. Enable Warehouse on 1+ table. 2. Confirm FlightSQL is selected initially and its connection fields are visible. 3. Select DuckDB and confirm the catalogue switch is always visible. 4. Enable catalogue access and confirm the environment variables and SQL appear below in two numbered steps. 5. Switch back to FlightSQL and confirm the DuckDB steps disappear. 6. Set up Warehouse on a project where it is not yet enabled and confirm DuckDB catalogue access is not enabled automatically. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a query-engine selector for FlightSQL and DuckDB connection setups. * Added guided DuckDB setup steps, copy-to-clipboard support, and reveal/hide controls for secrets. * Added a catalog access toggle with confirmation feedback. * Catalog details load only when DuckDB is selected. * **Updates** * Streamlined warehouse connection layouts with consistent spacing. * Catalog access is now controlled separately from the initial warehouse setup. * Excluded sensitive setup details from copied prompts and added copy-status announcements. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Writing components
Where to create your components
- For components that declare the general structure and layout of a page:
/components/layouts/xxx
- For components that are tightly coupled to a specific interface:
/components/interfaces/xxx
- For components that are meant to be reusable across multiple pages:
/components/ui/xxx
- Note: We're gradually moving files out of the
to-be-cleanedfolder into the respective folders as we refactor
Component structure
- If a component has constants and utility methods that are tightly coupled to itself, keep them close to the component and enclose them in a folder with an
index.tsxas an entry point - Otherwise it can just be a file on its own
- For example:
-
components/ui - SampleComponentA - SampleComponentA.tsx - SampleComponentA.constants.ts - SampleComponentA.utils.ts - SampleComponentA.types.ts - index.ts - SampleComponentB.tsx
-
Template for building components
// Declare the prop types of your component
interface ComponentAProps {
sampleProp: string
}
// Name your component accordingly — use a named export, not a default export
export const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}