[IMPLEMENTED PARTLY] Migrate schemas and rules between apps

I have started with the sync logic a little bit: https://github.com/Squidex/squidex-samples/blob/sync/cli/Squidex.CLI/Squidex.CLI/Commands/App_Schemas.cs#L70

With the CLI you can manage your configs, so you could use it like this:

sq config add ... -label myapp-prod
sq config add ... -label myapp-dev

// Use dev config
sq config use myapp-dev
// Save schema in file
sq schema get my-schema >> temp.json
// Switch to ´production
sq config use myapp-prod
// Sync schema in
sq schema sync temp.json

Do you want to continue and provide a PR? :wink:

1 Like

Man you’re fast! I hope to find some time this week to follow up.

But it is not ready yet, I just started with the development. But the idea should be clear.

It will be released this week.

Looking forward to it :-). We’ve been struggeling to find time to contribute to this.

No problem. I solved it in a totally different way now. it is integrated directly into the api.

Hi, there is a no sync endpoint: https://cloud.squidex.io/api/docs#operation/Schemas_PutSchemaSync

Here is how to you use it: https://github.com/Squidex/squidex-samples/blob/master/cli/Squidex.CLI/Squidex.CLI/Commands/App_Schemas.cs#L69

1 Like

Hey @Sebastian

How does this API call work?

It looks like it will create the schema if it doesn’t exist on the target, which is great. How is it picking up the base application? I don’t see where that is specified.

I am new to the CLI and haven’t even got it running yet, so appreciate your patience. Any documentation you may have to get started with it would be great.

Hi @blakecodes

the API works on specific schema, so it must exist. If it does not exist, you have to create a new schema first, but the json schema for the request body is the same.

So what you can do:

  1. Read schema1 and save the json to file.
  2. Read file and forward it to schema2 on the same or another app.

Squidex will then make all the changes that are necessary to keep both schemas in sync.

The CLI manages connections to multiple apps. First you have to register the app:

sq config add <app> <app:client> <secret>

You can switch between apps with

sq config use <app>

Then you have to download the schema from one app and store it to a file, e.g.

// Connect to app1
sq config use app1
// Download schema1 from app1
sq schemas get schema1 > schema.json
// Connect to app2
sq config use app2
// Sync the schema with the schema name from the json
sq schemas sync schema.json
// OR use another schema name
sq schemas sync schema.json -name schema2

Documentation is on my todo list, but I wanted to wait for the first responses about the CLI first.

1 Like

@Sebastian

I’ll give it a shot over the weekend, thanks for the insight.

Do you have an example .configuration I can use?

What configuration do you mean?

If you click the connect button for a client you will get a dialog with a command to connect the cli to the app with this client:

Wow, never seen that. Awesome!

Hi Sebastian,

Works like a charm. We’ve packed the CLI tool in an internal Nuget package which is included in our Visual Studio projects. This way we can easily update a local copy of the schemas in our solution. This way we always have a matching schema in json within our solution.

On deployment using Octopus Deploy we use these json files to update the corresponding Squidex app along with installing our webapp.

Bottom line. Changes to schemas are now part of our regular automated deployment process. Many thanks for that!

On thing i’ve noticed is that fields with references are not transfered proberly (because the schemaId will be different). It’s not such a problem to change these afterwards. But downside is that manual changes will be overwritten with the next sync. Any thoughts or directions to fix this?

Many thanks,
Marcel

Yes, I am aware of the problem with the schema id. It is on my todo list :wink:

The problem is that right now the CLI tool does not have the necessary information. It either needs all schemas from the source and target app or the name of the referenced schemas. I tend to use the second approach.

Using the name should work making sure not to overwrite manual changes.

Something like:

  • If name is found in target > reference that target schema
  • If name is not found in target but other schema is referenced in target > leave reference as it is (might be manually corrected)
  • Else target = null.

I published a new version of the CLI that does exactly that.

When you retrieve a schema you can save it with the names of the referenced schemas
When you sync a schema this information is used to reassign the referenced schema ids.

Superb. I’ll give it a try over the weekend. Is see the new release on https://github.com/Squidex/squidex-samples/releases. I’m building the cli from the source which has not been updated yet (not pushed yet?)

Sorry, will do it tomorrow morning.