Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2301.1 compatible: Invalid property type names #112

Open
pkoellner-extern-arvato opened this issue Jul 12, 2023 · 1 comment
Open

2301.1 compatible: Invalid property type names #112

pkoellner-extern-arvato opened this issue Jul 12, 2023 · 1 comment

Comments

@pkoellner-extern-arvato
Copy link

pkoellner-extern-arvato commented Jul 12, 2023

Hi, I am integrating core-forms-cmcc-11-2301.1.tar.gz into a workspace with cm11 2301.1 and a postgresql 42.5.1 database for the repository. After adding the extension and starting the content-server, I get the following error:

content-management-server | [ERROR] (Init Process) hox.corem.server.Server [] - Cannot startup due to malformed document type definition: Invalid names in document type definition: spamProtectionEnabled, reason is: Invalid property type name: spamProtectionEnabled, aborting

The Content Server Manual, 4.1. states:

Caution

The name can have a maximum length of 18 characters (DateProperty field names only 15 characters) and must not contain umlauts or other special characters ("§", "&", ...). Two fields in a content type different only in upper or lower case are not allowed. Furthermore, a name's last character must not be an underscore, since these field names are reserved for CoreMedia.

"spamProtectionEnabled" is 21 chars long, "pageableFormEnabled" 19 chars, which is too long in both cases. This may work with some databases, but apparently not with postgresql.

As a workaround, I am changing them locally to "spamProtection" and "pageable", since the "Enabled" is implicated in the boolean value... (Replace all in project, preserve case: spamProtectionEnabled -> spamProtection,, pageableFormEnabled -> pageable, don't forget to rebuild studio-client after change - no longer integrated with maven)

@timolemke
Copy link

Hi, thanks for the report.
You are right, we did not take "Content Server Manual, 4.1." into account when introducing the new docType properties.

Unfortunately, if we change the property names now, it would cause migration troubles for projects using compatible databases, e.g. MySQL. We could rename the properties in the docTypes.xml and make the ContentBeans and Studio-Forms backwards compatible. Do you have any idea, how such a compatible studio component could look like?
@FabitUsJanHendrikPopp have you ever built such a studio component?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants