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

[FEATURE] Consolidate Consumed CSN Flavours #128

Open
daogrady opened this issue Dec 19, 2023 · 0 comments · May be fixed by #356
Open

[FEATURE] Consolidate Consumed CSN Flavours #128

daogrady opened this issue Dec 19, 2023 · 0 comments · May be fixed by #356
Labels
feature request New feature or request keepalive Will not be closed by Stale bot

Comments

@daogrady
Copy link
Contributor

Description

Two Flavours

cds-typer nowadays uses two flavours of CSN to operate: xtended and inferred flavour.
The inferred flavour is generally superior in our case, as it contains fields that are computed later down the pipeline, like properties from CQN selections, annotations, and so on. These are all fields we are expecting in our generated type files.

The xtended flavour on the other hand does not propagate fields from inherited entities to child entities. Consider the following CDS file:

entity A {
    id : Integer;
}

entity B: A {
    name: String;
}

Loading it with the inferred flavour will generate this CSN snippet:

    A: {
      kind: 'entity',
      elements: { id: { type: 'cds.Integer' } }
    },
    B: {
      kind: 'entity',
      includes: [ 'A' ],
      elements: {
        id: { type: 'cds.Integer' },
        name: { type: 'cds.String' }
      }
    }
  }

which would (more or less) result in the following classes:

class A {
  id: number;
}

class B extends A {
  id: number;  // <- duplicate!
  name: string;
}

This duplicate is not present when using the xtended flavour instead.

Ramifications

As the compilation step is not discrete and/pure, we need to load the entire model twice. This can be a considerable hit on the execution time.
Having both flavours can also be rather confusing. We constantly need to juggle them and remember which flavour to use in which use case.

Suggested Solution

We should get rid of one of the two flavours. As inferred CSN is more complete, the xtended flavour should probably be dropped. Instead of rectifying the xtended flavour with unrolled annotations, we should aim to deduplicate properties in the inferred flavour instead.

Alternatives

Wait for universal CSN or modify xtended CSN even more to be closer to inferred CSN.

Additional Context

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request keepalive Will not be closed by Stale bot
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant