feat: workspace sync #3505
feat: workspace sync #3505
Conversation
fix: clean
magrinj
force-pushed
the
feat/workspace-sync
branch
from
ae63f94 to
e809d04
Compare
| @@ -113,6 +113,9 @@ export class WorkspaceMigrationRunnerService { | |||
| tableMigration?.columns, | |||
| ); | |||
| break; | |||
| case 'drop': | |||
| await queryRunner.dropTable(`${schemaName}.${tableMigration.name}`); | |||
There was a problem hiding this comment.
How do we handle dropping tables that are referenced in other tables with non-nullable FK?
There was a problem hiding this comment.
Actually dropping is still a work in progress, I just commit the change on this part but doesn't implement it.
But you're point is good, we'll have to drop the other table before
...rver/src/workspace/workspace-sync-metadata/comparators/utils/order-object-properties.util.ts
Show resolved
Hide resolved
| (field) => field.name === fieldName, | ||
| ); | ||
| const originalFieldMetadata = originalObjectMetadata.fields.find( | ||
| (field) => field.name === fieldName, |
There was a problem hiding this comment.
I've created a ticket here #3621 in preparation. We will want to use something else here as we already discussed 🙂
There was a problem hiding this comment.
Thanks ! I had planned to create this kind of ticket tomorrow 🙂
|
|
||
| for (const difference of fieldMetadataDifference) { | ||
| const fieldName = difference.path[0]; | ||
| // Object shouldn't have thousands of fields, so we can use find here |
There was a problem hiding this comment.
nit:Otherwise we can also create a map<fieldName, field> for faster access?
There was a problem hiding this comment.
@Weiko Yes I think of it too, but I think it's a bit too much and add more variables and "complexity"
...wenty-server/src/workspace/workspace-sync-metadata/comparators/workspace-field.comparator.ts
Outdated
Show resolved
Hide resolved
...enty-server/src/workspace/workspace-sync-metadata/comparators/workspace-object.comparator.ts
Outdated
Show resolved
Hide resolved
| import { FeatureFlagEntity } from 'src/core/feature-flag/feature-flag.entity'; | ||
|
|
||
| @Injectable() | ||
| export class FeatureFlagFactory { |
There was a problem hiding this comment.
Just to clarify with the pattern we want to use. Here it seems that's something we would have originally simply put in the FeatureFlagService with a method taking a workspaceId as a parameter. What's the benefit here? Factories usually intervene when we want to instantiate complex objects so I'm wondering if this is necessary here? Or at least let's decide a pattern here because I know we don't do that for metadata module for example 🙂
There was a problem hiding this comment.
In my mind, factories can be used when the create or modify an object based on other object, and we're creating a map of feature flags [key: value], it's why I've created a factory.
But if we think it can be used in other part of the code we can move it into FeatureFlagService
There was a problem hiding this comment.
To your last point: I think we will want this function in other places. Not fully sure though since usually we want to query over a specific featureFlag key and we don't need all of them but could be useful I guess 🙂
There was a problem hiding this comment.
I guess we can move it later if we need it ?
...ages/twenty-server/src/workspace/workspace-sync-metadata/factories/workspace-sync.factory.ts
Show resolved
Hide resolved
...ver/src/workspace/workspace-sync-metadata/services/workspace-sync-object-metadata.service.ts
Outdated
Show resolved
Hide resolved
packages/twenty-server/src/workspace/workspace-sync-metadata/workspace-sync-metadata.service.ts
Show resolved
Hide resolved
This PR introduces a comprehensive refactoring of the
workspace:sync-metadatacommand, alongside addressing various bug fixes. The refactoring aimed to enhance code modularity, readability, and maintainability. Key changes include the creation of new directory structures and classes, each serving a distinct purpose in the metadata synchronization process.Comparators Directory: This directory contains class designed to compare standard objects against their database counterparts. The primary function of this class is to effectively identify differences.
Factories Directory: The factories directory goal is to contain object generation class. It contains logic to create new objects based on provided data. A typical use case involves creating Standard objects derived from decorators.
Services Directory: Just here for more readability.
Storage Directory: This directory serves as a memory storage for the
create,update, anddeletecollections. Its primary purpose is to support operations like the dropping of fields, objects, or relations, thereby providing a robust mechanism for managing changes within the metadata environment.Fix #3442