Dulajdeshan
commented
2 weeks ago @CodewithDili Hi I'm not quite sure I got your request.
In order custom fields to be work, you should add those to the content type. This would change your existing data model by addition of newly created custom field. This is how Strapi works and it cannot be changed.
It would be great if you could explain your request with an example.
Thanks.
Description: It would be helpful to add functionality that allows UUID integration with existing content types in a Strapi project without requiring a data migration or manual changes to the current content models. This would enable seamless adoption of UUIDs for projects with pre-existing data, minimizing disruption.
Problem Statement: Currently, integrating UUIDs with established content types may require developers to alter their existing data structure, potentially leading to downtime, migration complexity, or data integrity risks. For larger datasets, this process can be time-consuming and may interfere with the production environment.
Proposed Solution: Introduce an option to activate UUIDs directly on existing content types without changing the underlying data model. Provide a configuration or admin UI option where UUIDs can be optionally generated only for new entries, leaving existing entries unchanged. Consider including a "backfill" option for existing content if users want to add UUIDs retroactively but keep this as a separate, non-default option.
Use Cases: Projects with existing data want to introduce UUIDs only for future content. Teams want a simple, non-invasive way to apply UUIDs without data migration. Organizations with production databases seek UUID integration without risking data stability. Additional Context: A UUID integration without data migration would improve compatibility for projects transitioning from other systems or those scaling up where unique identifiers become essential.
Example Issue Title: "Enable UUID integration with existing content types without data migration"