You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Built-in support for UUIDs would allow users to take advantage of known semantics of UUIDs and avoid having to redefine complex regular expressions. Using a built-in type (rather than a faceted typedef, #433 ) would allow us to also generate default values (such as for UUIDv4).
Adding a new primitive types is likely quite expensive (requires all code gen visitors to be updated to handle this type, as well as changing the metamodel). A middle path could be to add support for typedefs (a faceted String) and then to put some of these common typedefs into a concerto.types namespace. This would allow codegen and instance gen to be updated progressively. We could then decide whether concerto.types was an implicit import into all namespaces...
It's common for models to need to define properties or identifiers that follow a uniqueness constraint, e.g. following the UUID (universally unique identifiers) standard. https://en.wikipedia.org/wiki/Universally_unique_identifier
Built-in support for UUIDs would allow users to take advantage of known semantics of UUIDs and avoid having to redefine complex regular expressions. Using a built-in type (rather than a faceted typedef, #433 ) would allow us to also generate default values (such as for UUIDv4).
Feature Request 🛍️
Use Case
Possible Solution
Context
Detailed Description
The text was updated successfully, but these errors were encountered: