mirror of
https://github.com/twentyhq/twenty.git
synced 2024-11-28 09:12:37 +03:00
e976a1bdfc
## Context We recently enabled the option to bypass SSL certificate authority validation when establishing a connection to PostgreSQL. Previously, if this validation failed, the server would revert to unencrypted traffic. Now, it maintains encryption even if the SSL certificate check fails. In the process, we overlooked a few DataSource setups, prompting a review of DataSource creation within our code. ## Current State Our DataSource initialization is distributed as follows: - **Database folder**: Contains 'core', 'metadata', and 'raw' DataSources. The 'core' and 'metadata' DataSources manage migrations and static resolver calls to the database. The 'raw' DataSource is utilized in scripts and commands that require handling both aspects. - **typeorm.service.ts script**: These DataSources facilitate multi-schema connections. ## Vision for Discussion - **SystemSchema (formerly core) DataSource**: Manages system schema migrations and system resolvers/repos. The 'core' schema will be renamed to 'system' as the Core API will include parts of the system and workspace schemas. - **MetadataSchema DataSource**: Handles metadata schema migrations and metadata API resolvers/repos. - **(Dynamic) WorkspaceSchema DataSource**: Will be used in the Twenty ORM to access a specific workspace schema. We currently do not support cross-schema joins, so maintaining these DataSources separately should be feasible. Core API resolvers will select the appropriate DataSource based on the field context. - **To be discussed**: The potential need for an AdminDataSource (akin to 'Raw'), which would be used in commands, setup scripts, and the admin panel to connect to any database schema without loading any model. This DataSource should be reserved for cases where utilizing metadata, system, or workspace entities is impractical. ## In This PR - Ensuring all existing DataSources are compliant with the SSL update. - Introducing RawDataSource to eliminate the need for declaring new DataSource() instances in commands.
39 lines
1022 B
TypeScript
39 lines
1022 B
TypeScript
import console from 'console';
|
|
|
|
import { rawDataSource } from 'src/database/typeorm/raw/raw.datasource';
|
|
|
|
import { performQuery } from './utils';
|
|
|
|
async function dropSchemasSequentially() {
|
|
try {
|
|
await rawDataSource.initialize();
|
|
|
|
// Fetch all schemas
|
|
const schemas = await performQuery(
|
|
`
|
|
SELECT n.nspname AS "schema_name"
|
|
FROM pg_catalog.pg_namespace n
|
|
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
|
|
`,
|
|
'Fetching schemas...',
|
|
);
|
|
|
|
// Iterate over each schema and drop it
|
|
// This is to avoid dropping all schemas at once, which would cause an out of shared memory error
|
|
for (const schema of schemas) {
|
|
await performQuery(
|
|
`
|
|
DROP SCHEMA IF EXISTS "${schema.schema_name}" CASCADE;
|
|
`,
|
|
`Dropping schema ${schema.schema_name}...`,
|
|
);
|
|
}
|
|
|
|
console.log('All schemas dropped successfully.');
|
|
} catch (err) {
|
|
console.error('Error during schema dropping:', err);
|
|
}
|
|
}
|
|
|
|
dropSchemasSequentially();
|