Please, let's use parseIdentifier

Please, use createIdentifier

Please, let's use parseIdentifier

Let's avoid using let when possible. This method could be refactored this way:

        async getFormStats(this: FormBuilder, formRevisionId) {
            const id = getFormStatsId(formRevisionId);

            try {
                const formStats = await this.storageOperations.formStats.getFormStats({
                    where: { id, tenant: getTenant().id, locale: getLocale().code }
                });

                if (!formStats) {
                    throw new NotFoundError("Form stats not found.");
                }

                return formStats;
            } catch (ex) {
                throw new WebinyError(
                    ex.message || "Could not load form stats.",
                    ex.code || "GET_FORM_STATS_ERROR",
                    {
                        id
                    }
                );
            }
        }

Same here, let's avoid using let when possible.

We should create the formStats entry only if the form entry is successfully created.

Right now, we are trying to create the formStats entry even when the creation fails, right?

The code inside the try-catch will throw an error if the form is not created. This prevents the formStats section from being executed. The same applies to the next two comments as well.

Ok, let's throw a meaningful error in case the formStats creation fails, something like:

throw new WebinyError(
    ex.message || "Could not create form.",
    ex.code || "CREATE_FORM_STATS_ERROR",
    {
        form
    }
);

Errors are already implemented for all formStats CRUD operations.

In the createForm method, if form creation fails, it will throw a CREATE_FORM_ERROR. If it succeeds, the createFormStats method is executed, which, in case of failure, will throw a CREATE_FORM_STATS_ERROR.

Similarly, in the createFormRevision method, if form revision creation fails, a CREATE_FORM_FROM_ERROR is thrown. However, if the form revision is successfully created but createFormStats fails, a CREATE_FORM_STATS_ERROR is thrown.

Lastly, for deleteForm, if form deletion fails, it throws a DELETE_FORM_ERROR. Conversely, if the form is deleted successfully but deleteFormStats encounters an error, a DELETE_FORM_STATS_ERROR is thrown.

Same here, see my comment above.

Same here, we should not delete the formStats entry if the form entry deletion fails.