At field creation we are checking the availability of the name by comparing it to the other fields' names' on the object; but for composite fields the fields' names' as indicated in the repository do not exactly match the column names' on the tables (e.g "createdBy" field is actually represented by columns createdByName, createdBySource etc.). In this PR we prevent the conflict with the standard composite fields' names. There is still room for errors with the custom composite fields: for example a custom composite field "address" of type address on a custom object "listing" will introduce the columns addressAddressStreet1, addressAddressStreet2 etc. while we won't prevent the user from later creating a custom field named "addressAddressStreet1". For now I decided not to tackle this as this seem extremely edgy + would impact performance on creation of all fields while never actually useful (I think).
15 lines
674 B
TypeScript
15 lines
674 B
TypeScript
import { InvalidStringException } from 'src/engine/metadata-modules/utils/exceptions/invalid-string.exception';
|
|
import { NameTooLongException } from 'src/engine/metadata-modules/utils/exceptions/name-too-long.exception';
|
|
import { exceedsDatabaseIdentifierMaximumLength } from 'src/engine/metadata-modules/utils/validate-database-identifier-length.utils';
|
|
|
|
const VALID_STRING_PATTERN = /^[a-z][a-zA-Z0-9]*$/;
|
|
|
|
export const validateMetadataNameValidityOrThrow = (name: string) => {
|
|
if (!name.match(VALID_STRING_PATTERN)) {
|
|
throw new InvalidStringException(name);
|
|
}
|
|
if (exceedsDatabaseIdentifierMaximumLength(name)) {
|
|
throw new NameTooLongException(name);
|
|
}
|
|
};
|