Problem with reusable schema migration and assignment

[VasileEcubed]

Brief bug description

In our old Kentico 13 project, we have a base page type that contain a list of fields that are inherited by other page types.
At the moment the tool allows migrating class into reusable schema by using CreateReusableFieldSchemaForClasses.
This migration will not attach reusable schema to the child content type.
We've tried to implement that custom mapper from ClassMappingSample, but the code priovided does not attatch reusable schema. We've tried some custom code there, but the problem is that the schema inherited fields contain prefix {page_type_code_name}__{field_name}, but we want to keep same name for those fields and the data is not pupulated in those fields.

Is there are other configuration that we might need, in order to achieve this result?

Expected behavior

Please see additional screenshots for more visual demonstration of the problem.

• Actual behaviour when migrate classes via CreateReusableFieldSchemaForClasses (The schema was attached to class via custom code. By default schema is not attached to classes)

• Expected behaviour when migrate classes via CreateReusableFieldSchemaForClasses

Dev environment

• Xperience by Kentico version 30.3.1
• Migration tool: 3.3.1

[liparova]

Hi! Thanks for reporting this! Our team will check it out and keep you posted.

[DavidSlavik]

Hi @VasileEcubed,

We are going to test your scenario to ensure there is not any bug. In the meantime, I would like to kindly ask you to share your configuration code where you set up the Reusable Field Schema. This could help us to test your scenario the best and possibly propose changes for a successful run.

David

[VasileEcubed]

Hi @DavidSlavik ,
Thanks for looking into this. I’ve uploaded the configuration code for the Reusable Field Schema to Google Drive — you can access it here
Let me know if you need anything else!

Best,
Vasile

[akfakmot]

Hi @VasileEcubed ,

I analyzed your code. Please see the attached file for detailed explanation. I've prefixed my comments with // EFFECT

code-analyzed.txt

Your general idea of using the class mapping to achieve what you want is very good. But class mapping was designed as configuration for future migration execution and you are mixing the configuration with operations that have immediate effect.

Summary:

1. The reusable schema prefix is by-design behavior of current version of MT.
2. That your fields end up empty is a result of your code not doing operations at the correct stage of migration. When MT uses custom mapping, the stages are:
   I. User's custom class mapping configures MT for future execution of migration
   II. Parent page types are mapped. At this point reusable schema is created based on ClassNamesCreateReusableSchema configuration within --page-types command handler
   III. Child page types are mapped. MT really doesn't support attaching parent's reusable schema to child class at this point - more on that below
   IV. Pages are mapped - at this stage the mapping will use custom class mapping code's configuration to perform what the user configured

Solution:
Due to how the MT stages are ordered, the simplest solution that I demo here below (here Cinema is the child class), won't work. That's because manual mappings are executed as the very first in page-types command handler, and creation of reusable schema comes only after that.

var m = new MultiClassMapping("namespace.Cinema", target =>
{
    target.ClassName = "namespace.Cinema";
    target.ClassTableName = "namespace_Cinema";
    target.ClassDisplayName = "Cinema";
    target.ClassType = ClassType.CONTENT_TYPE;
    target.ClassContentTypeType = ClassContentTypeType.WEBSITE;
});

m.BuildField("CinemaID").AsPrimaryKey();
m.UseResusableSchema("namespace_pagebase");
m.BuildField("Name").SetFrom("namespace.Cinema", "Address");
// build other fields
serviceCollection.AddSingleton<IClassMapping>(m);
return serviceCollection;

Viable option 1:
This one is laborous, but it's possible to create the reusable schema manually using ReusableSchemaBuilder as you see in AddReusableSchemaIntegrationSample sample.
You'd have to define all the fields with their properties, that's the laborous part. You could make your life easier by leveraging some generative AI chatbot. You can e.g. provide it with CMS_Class.ClassFormDefinition and/or CREATE TABLE script and explain what code you want on the output.

Viable option 2:
Raise a feature request since this is not a bug. Specifically ask for 2 features:
1. Ability to create RS without prefix and
2. If a parent class is converted to reusable schema, attach the RS to each of its child classes

[DavidSlavik]

As a result of this Issue, we've created this feature request: #426

@VasileEcubed, can you give us an indication of urgency for this, please?

[bluemodus-mwills]

@DavidSlavik -- since my team has been successfully migrating content models with reusable schema, I thought it'd be useful to share how we handle the scenarios above.

We originally made a similar request in #242, but at the same time, requested the ability to completely customize page types during the migration in #241.

Even in issue #242, we agreed that the first request wouldn't be needed if the bigger enhancement in #241 was provided.

This could get complex, so the preferred solution would be to add this capability to the request in #241.

So, our practice is to do exactly what @akfakmot eluded to. We don't use ClassNamesCreateReusableSchema configuration at all. Instead, we use ReusableSchemaBuilder to define all the new reusable schemas that we want in XbyK. These are typically more granular than the base page types coming from a KX13 project, which makes it much easier to mix and match small groups of reusable fields.

But to do this, we have to make sure the old KX13 base types are out of the way. Otherwise, their fields will be automatically migrated, and prevent us from using the same field names in the new reusable schemas. Therefore, we add a class mapping, that maps those base page types to a "delete me" type with no fields. We can delete that type in XbyK when we're done.

using CMS.DataEngine;
using Microsoft.Extensions.DependencyInjection;
using Migration.Tool.Common.Builders;

namespace Migration.Tool.Extensions.ClassMappings;

public static class DeleteClassMap
{
    public static IServiceCollection AddDeleteClassMap(this IServiceCollection serviceCollection)
    {

        var m = new MultiClassMapping("DeleteMe.DeleteMe", target =>
        {
            target.ClassName = "DeleteMe.DeleteMe";
            target.ClassTableName = "DeleteMe_DeleteMe";
            target.ClassDisplayName = "DeleteMe";
            target.ClassShortName = "DeleteMe";
            target.ClassType = ClassType.CONTENT_TYPE;
            target.ClassContentTypeType = ClassContentTypeType.REUSABLE;
            target.ClassWebPageHasUrl = false;
            target.ClassGUID = new Guid("3d753fa9-9442-406a-ace7-c7f8a88ffec2");
        });

        m.BuildField("ContentItemDataID").AsPrimaryKey();

        // One arbitrary (but existing) field for each dumped class
        m.BuildField("NavigableItemBase")
            .SetFrom("Acme.NavigableItemBase", "DocumentTitle", true);
        m.BuildField("ListableItemBase")
            .SetFrom("Acme.ListableItemBase", "ItemLinkText", true);

        serviceCollection.AddSingleton<IClassMapping>(m);


        return serviceCollection;
    }
}

We also ensure we provide a mapping class for every type we are migrating to ensure, all of them use the new reusable schemas, and to prevent automatic migration of fields that would conflict with the field names we are using in the new reusable schemas. This seems like a lot, but we have made it easier by generating the mapping classes from a spreadsheet that maps the old types to the new types.

So, a good solution could be to:

• Not allow using ClassNamesCreateReusableSchema with the ReusableSchemaBuilder, because this scenario is very complicated. If your migration is going to do custom class mapping, it needs to own all the types to avoid field name conflicts.
• Provide a way to define types that should be ignored. Although, the way we are doing it above is pretty simple.

I hope this helps.

[DavidSlavik]

@liparova please estimate the following two points:

• Not allow using ClassNamesCreateReusableSchema with the ReusableSchemaBuilder, because this scenario is very complicated. If your migration is going to do custom class mapping, it needs to own all the types to avoid field name conflicts.
• Provide a way to define types that should be ignored. Although, the way we are doing it above is pretty simple.

[liparova]

@DavidSlavik we'll take a look at it and let you know.

[liparova]

Hi @VasileEcubed @bluemodus-mwills @DavidSlavik

We’ve reviewed both points and will aim to deliver a solution sometime next week. We’ll keep you updated on the progress.