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

Duplicate type definitions generated for compositions to aspects #35

Open
frankmeertens opened this issue Jul 26, 2022 · 1 comment
Open
Labels
bug Something isn't working

Comments

@frankmeertens
Copy link

The compositions translate to the composition name, rather than the corresponding entity or aspect name. As a result duplication issues might occur when the same composition name is used, while pointing to two distinct aspects or entities.

Using the entity or aspect name, rather than the composition name looks like

Example data model definition:

namespace my.bookshop;

entity Books {
  key ID         : Integer;
      title      : String;
      stock      : Integer;
      Attributes : Composition of many Book_Attributes;
}

aspect Book_Attributes {
  key code  : String(10);
  bookValue : String;
}

entity CDs {
  key ID         : Integer;
      title      : String;
      stock      : Integer;
      Attributes : Composition of many CD_Attributes;
}

aspect CD_Attributes {
  key code : String(10);
  cdValue  : String;
}

Books and CDs has a similarly named composition, but refer to two distinct aspects (entities). However, when the types are being created, the name of the composition is used, rather than the name of the corresponding entity.
Below is the result of the data model definition above.

export namespace my.bookshop {
    export interface IBooks {
        ID: number;
        title: string;
        stock: number;
        Attributes: IAttributes[];
    }

    export interface ICDs {
        ID: number;
        title: string;
        stock: number;
        Attributes: IAttributes[];
    }

    export interface IAttributes {
        up_?: IBooks;
        up__ID?: number;
        code: string;
        bookValue: string;
    }

    export interface IAttributes {
        up_?: ICDs;
        up__ID?: number;
        code: string;
        cdValue: string;
    }

    export enum Entity {
        Books = "my.bookshop.Books",
        CDs = "my.bookshop.CDs",
        Attributes = "my.bookshop.CDs.Attributes"
    }

    export enum SanitizedEntity {
        Books = "Books",
        CDs = "CDs",
        Attributes = "Attributes"
    }
}

export enum Entity {
}

export enum SanitizedEntity {
}

Notice the duplication of the IAttributes interface definition, as well as the Entity and SanitizedEntity enum.
A current workaround that can be used is to ensure unique composition naming with the corresponding namespace.

The underlying issue, I think is the interpretation between a composition of an Entity versus the composition of an Aspect. In case of an entity, the target of the definition in csn is the reference entity name. In case of an aspect, the target of the definition is my.bookshop.Books.Attributes and there is an additional target_aspect field that contains the name of the aspect. The cds2types conversion (resolveTargetType) for the composition seems to be based on the target name, which provides the right information. However, the name is sanitized and only retains the last part of the name, separated by periods.
In the above example, the same composition name results in duplicate definitions.

@frankmeertens frankmeertens changed the title Composition translates to composition name, rather than corresponding entity Duplicate type definitions generated for compositions to aspects Jul 26, 2022
@thisisevanfox
Copy link
Collaborator

Hi @frankmeertens,

We'll look into this one. Thanks for reporting.

Kind regards
Johannes

@thisisevanfox thisisevanfox added the bug Something isn't working label Nov 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants