@ThatOneGoose Let's create a demo env id
@ThatOneGoose Let's create a demo env id and store it in server .env. We will need to be able to identify this demo environment. Also, your seeds should only touch data and not metadata (telling that because your screenshot shows metadata seed Ids)
49 Replies
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
@ThatOneGoose sorry, I was super busy! We want a dedicated command to seed the demo workspace which is different from the developement seeds
So we want a command that's very similar to the seed one (let's call it the dev-seed command) that would create a demo workspace and run demo-seeds
I think we can make something very symetric with the dev-seed one
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
we should create new users!
maybe seedDevUsers() <> seedDemoUsers()
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
yes correct!
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
metadata are tied to a workspace but we should insert exaclty the same for the two workspaces
so you should not modify them
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
you should maybe modify it to seedMetadataSchema(workspaceId)
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
nice!
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
ok 🙂
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
feel free to push code and ping me on the PR or here if you need assistance
so, to summarize, we want to create a new workspace with its own data, this means:
1. Create core entities in core schema related to this new workspace (a new Workspace, a new set of users)
2. Seed metadatas in the metadata schema. This means inserting into metadata table the same data as for seed but with the new workspace_id (dataSource, objectMetadata, fieldMetadata, relationMetadata)
3. Create the workspace schema, insert and run migrations on this schema
4. Seed the workspace schema (workspace_xxxxxxx) that the new metadata datasource row should point to. With the demo data
This is more or less what's in
data-seed-workspace.command.tsUnknown User•12mo ago
Message Not Public
Sign In & Join Server To View
1. await seedCoreSchema(dataSource);
2. await seedMetadataSchema(dataSource);
3. await this.workspaceMigrationService.insertStandardMigrations(
this.workspaceId,
);
await this.workspaceMigrationRunnerService.executeMigrationFromPendingMigrations(
this.workspaceId,
);
4. await seedCompanies(workspaceDataSource, dataSourceMetadata.schema);
await seedPeople(workspaceDataSource, dataSourceMetadata.schema);
await seedPipelineStep(workspaceDataSource, dataSourceMetadata.schema);
await seedOpportunity(workspaceDataSource, dataSourceMetadata.schema);
await seedViews(workspaceDataSource, dataSourceMetadata.schema);
await seedViewFields(workspaceDataSource, dataSourceMetadata.schema);
await seedWorkspaceMember(workspaceDataSource, dataSourceMetadata.schema);
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
Hold on, there is a tricky part actually
Regarding 2.
"This means inserting into metadata table the same data as for seed" ==> this is not true. Right now, we hard code the fieldMetadataIds and objectMetadataIds which means you'll have duplicates
In your command. Instead of calling
await seedMetadataSchema(dataSource);
mmmmh
Ok, so instead of what I'm saying above, could you mimick the init function from workspace-manager.service.ts
It's doing the same as our seed command but in a more flexible way
So:
1. same as above
2. 3. 4. Use the logic from the init function from workspace-manager.service.ts instead. It will give you way more flexibility. We will likely also migrate the seed toward a similar logic in the upcoming days
What's important is to use:
await this.prefillWorkspaceWithStandardObjects(
dataSourceMetadata,
workspaceId,
createdObjectMetadata,
);
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
Good luck, I will be highly available here if you need!
And it's going very well! Very happy with the new arch.
Yes, I'm going to build the containers today! Hopefully it will run like a charm on render
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
Building this flexible schema was a very long and hard task. Took us 2 months with ~8 engineers 100% focused on that. But it can be serious CRM without that
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
4) is the best option as we will be able to typecheck it and make it evolve easily when we update types
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
@Weiko :p
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
yes, let's create another set of DemoUserIds
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
I feel they should be two complete differents sets (we might want to have 10 workspaceMembers in demo but 3 in seed)
So, I would duplicate the files and if else while seeding or demo-filling!
Would that work?
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
Yes !
we have removed table virtualization but we want to put it back to prevent this laggy behavior
Is: https://github.com/twentyhq/twenty/pull/2307 ready for review?
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
I'm taking a look at your PR in a few mins
I have merged main into your branch, I have spotted several issue that I'm working on, will push to your branch shortly
Ok, I have pushed! Ready to merge, great work!
Merged!
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
Yep! I've answered on the issue
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
I don't think it will impact the performance of the app significantly
@Jérémy can help you to find the best spot to put the check
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
@Jérémy @ThatOneGoose I don't think it's a good idea! ApiKey is a standard object, Twenty will consider that there is something wrong with this workspace in the future if a standard object is missing
The product assumption is that all standard objects are presents in all workspaces
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
Users will be able to enable it through data model eventually :p
I think we need a way to block features on the BE ? is it really a problem to add a if case when receiving the query?
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
I think what we want long term is a "hook" logic to enable anybody to add logic on before or after a graphql call. This will be done in an abstract and scalable way. For now, we could just put that into a create-one-pre-hook.ts and call it in create-one-resolver.factory.ts? @Jérémy
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View
Re-thinking about ApiKey specifically, we could indeed remove it from the schema (tag the standard object as disable) and block re-activating it in /metadata updateObject endpoint, that would be acceptable too (not sure if it was what you mentionned before)
I still think that there will be cases that we want to block but leave in the schema. For example, in the future, we might want to prevent demo workspace member from changing the locale to another language. This would mean prevent a specific update on WorkspaceMember (updating locale) but allowing others (update color scheme for example)
in this case, we need a way add some business logic to our universal updateOne resolver
Unknown User•12mo ago
Message Not Public
Sign In & Join Server To View