Search

    Compiler Messages

    This page lists selected error messages and explanations on how to fix them. It is not a complete list of all compiler messages.

    Note on message IDs
    Message IDs are not finalized, yet. They can change at short notice.

    Explanations for certain cds compiler messages.

    Content

    anno-duplicate-unrelated-layer

    An annotation is assigned multiple times through unrelated layers.

    A layer can be seen as a group of connected sources, for example CDL files. They form a cyclic connection through their dependencies (for example, using in CDL). If there are no cyclic dependencies, a single CDL file is equivalent to a layer.

    Example

    Erroneous code example using four CDS files:

    // (1) Base.cds: Contains the artifact that should be annotated
    entity FooBar {  }
    
    // (2) FooAnnotate.cds: First unrelated layer to Base.cds
    using from './Base';
    annotate FooBar with @Anno: 'Foo';
    
    // (3) BarAnnotate.cds: Second unrelated layer to Base.cds
    using from './Base';
    annotate FooBar with @Anno: 'Bar';
    
    // (4) All.cds: Combine all files
    using from './FooAnnotate';
    using from './BarAnnotate';
    

    In (4) the compiler will warn that there are duplicate annotations in unrelated layers. That is because (2) and (3) are unrelated, i.e. they do not have a connection.

    Due to these unrelated layers, the compiler can’t decide in (4) which annotation should be applied first.

    Instead of passing (4) to the compiler, you can also pass (2) and (3) to it. Because there are no cyclic dependencies between the files, each file represents one layer.

    How to Fix

    To fix the issue, remove one of the duplicate annotations. Chances are, that only one was intended to begin with. For the erroneous example above, remove the annotation from (3).

    Alternatively, add an annotation assignment to (4). This annotation has precedence and the error will vanish. For the example above, (4) will look like this:

    // (4) All.cds: Combine all files
    using from './FooAnnotate';
    using from './BarAnnotate';
    // This annotation has precedence.
    annotate FooBar with @Anno: 'Bar';
    

    You can also make (3) depend on (2) so that they are no longer in unrelated layers and the compiler can determine which annotation to apply.

    // (3) BarAnnotate.cds: Now depends on (2)
    using from './FooAnnotate';
    annotate FooBar with @Anno: 'Bar';
    

    This works because there is now a defined dependency order.

    check-proper-type-of

    An element in a type of expression doesn’t have proper type information.

    The message’s severity is Info but may be raised to Error in the SQL, SAP HANA, and OData backends. These backends require elements to have a type. Otherwise they aren’t able to render elements (for example, to SQL columns).

    Example

    Erroneous code example:

    entity Foo {
      key id : Integer;
    };
    view ViewFoo as select from Foo {
      1+1 as calculatedField @(anno)
    };
    entity Bar {
      // `e` has no proper type but has the annotation `@anno`.
      e : type of ViewFoo:calculatedField;
    };
    

    ViewFoo:calculatedField is a calculated field without an explicit type.

    type of is used in E:e’s type specification. You would expect the element to have a proper type. However, because the referenced element is calculated, the compiler isn’t able to determine the correct type. The element still inherits ViewFoo:calculatedField’s annotations and other properties but won’t have a proper type, which is required by some backends.

    How to Fix

    To fix the issue, assign an explicit type to ViewFoo:calculatedField.

    view ViewFoo as select from Foo {
      1+1 as calculatedField @(anno) : Integer
    };
    

    check-proper-type

    A type artifact doesn’t have proper type information.

    The message’s severity is Info but may be raised to Error in the SQL, SAP HANA, and OData backends. These backends require types to have type information. Otherwise they aren’t able to render elements that use this type (for example, to SQL columns).

    This message affects CSN input and shouldn’t appear if CDL input is used.

    Example

    Erroneous code example:

    {
      "definitions": {
        "MainType": {
          "kind": "type"
        }
      }
    }
    

    MainType is of kind “type” but has not further type information.

    How to Fix

    To fix the issue, add explicit type information to MainType, for example, add an elements property to make a structured type.

    {
      "definitions": {
        "MainType": {
          "kind": "type",
          "elements": {
            "id": {
              "type": "cds.String"
            }
          }
        }
      }
    }
    

    duplicate-autoexposed

    Two or more entities with the same name can’t be auto-exposed in the same service.

    Auto-exposure is a compiler feature which makes it easier for developers to write services. Auto-exposure uses the name of the entity to expose it in the service. It ignores the entity’s namespace and context. This may lead to name collisions.

    The message’s severity is Error and is raised by the compiler. You need to adapt your model to fix the error.

    Example

    Erroneous code example:

    // (1)
    entity ns.first.Foo {
      key parent : Association to one ns.Base;
    };
    // (2)
    entity ns.second.Foo {
      key parent : Association to one ns.Base;
    };
    // (3)
    entity ns.Base {
      key id    : UUID;
      to_first  : Composition of many  ns.first.Foo;
      to_second : Composition of many ns.second.Foo;
    }
    service ns.MyService {
      // (4)
      entity BaseView as projection on ns.Base;
    };
    

    Both (1) and (2) define an entity Foo, but in different namespaces. For example, they could be located in different files with a namespace statement. (3) contains compositions of both first.Foo and second.Foo.

    In (4), a projection on Base is exposed in service MyService. Both composition targets are auto-exposed. However, because the namespaces of (2) and (3) are ignored, a name collision happens.

    How to Fix

    To fix the issue, you need to explicitly expose one or more entities under a name that does not exist in the service, yet.

    For the erroneous example above, you could add these two lines to the service ns.MyService:

      entity first.Foo as projection on ns.first.Foo;   // (5)
      entity second.Foo as projection on ns.second.Foo; // (6)
    

    Here we reuse the namespaces first and second. We don’t use ns because it’s the common namespace. But you can choose any other name.

    The compiler will pick up both manually exposed entities and will correctly redirect all associations.

    Note: For the example, it is sufficient to expose only one entity. If you remove (6), you will get these two projections:

    • ns.MyService.first.Foo for (5)
    • ns.MyService.Foo for (6) Where (6) is the name chosen by the compiler.

    Notes on auto-exposure

    You may wonder why the compiler does not reuse the namespace when auto-exposing entities. The reason is that the resulting auto-exposed names could become long names that don’t seem natural nor intuitive. We chose to expose the entity name because that’s what most developers want to do when they manually expose entities.

    extend-repeated-intralayer

    The order of elements of an artifact may not be stable due to multiple extensions in the same layer (for example in the same file).

    A layer can be seen as a group of connected sources, for example, CDL files. They form a cyclic connection through their dependencies (for example, using in CDL).

    Example

    Erroneous code example with a single CDL file:

    entity FooBar { }
    
    extend FooBar { foo : Integer; }
    extend FooBar { bar : Integer; }
    

    Due to multiple extensions in the example above, the order of foo and bar inside FooBar may not be stable. You therefore can’t depend on it.

    It’s also possible to trigger this warning with multiple files. Look at the following example:

    // (1) Definition.cds
    using from './Extension.cds';
    entity FooBar { };
    extend FooBar { foo: Integer; };
    
    // (2) Extension.cds
    using from './Definition.cds';
    extend FooBar { bar: Integer; }
    

    Here we have a cyclic dependency between (1) and (2). Together they form one layer with multiple extensions. Again, the element order isn’t stable.

    How to Fix

    To fix the issue, move extensions for the same artifact into the same extension block:

    // (1) Definition.cds : No extension block
    using from './Extension.cds';
    entity FooBar { }
    
    // (2) Extension.cds : Now contains both extensions
    using from './Definition.cds';
    extend FooBar {
      foo : Integer;
      bar : Integer;
    }
    

    extend-unrelated-layer

    Unstable element order due to extensions for the same artifact in unrelated layers.

    A layer can be seen as a group of connected sources, for example CDL files. They form a cyclic connection through their dependencies (for example, using in CDL).

    Example

    Erroneous code example using four CDS files:

    // (1) Base.cds: Contains the artifact that should be extended
    entity FooBar {  }
    
    // (2) FooExtend.cds: First unrelated layer to Base.cds
    using from './Base';
    extend FooBar { foo : Integer; }
    
    // (3) BarExtend.cds: Second unrelated layer to Base.cds
    using from './Base';
    extend FooBar { bar : Integer; }
    
    // (4) All.cds: Combine all files
    using from './FooExtend';
    using from './BarExtend';
    

    In (4) the compiler will warn that the element order of FooBar is unstable. That is because the extensions in (2) and (3) are in different layers and when used in (4) it can’t be ensured which extension is applied first.

    Instead of passing (4) to the compiler, you can also pass (2) and (3) to it. Because there are no cyclic dependencies between the files, each file represents one layer.

    How to Fix

    To fix the issue, move extensions for the same artifact into the same layer, that is, the same file.

    For the erroneous example above, remove the extension from (3) and move it to (2):

    // (2) FooExtend.cds
    using from './Base';
    extend FooBar {
      foo : Integer;
      bar : Integer;
    }
    

    redirected-to-ambiguous

    The redirected target originates more than once from the original target through direct or indirect sources of the redirected target.

    The message’s severity is Error and is raised by the compiler. The error happens due to an ill-formed redirection, which requires changes to your model.

    Example

    Erroneous code example:

    entity Main {
          key id : Integer;
        toTarget : Association to Target;
    }
    
    entity Target {
        key id : Integer;
    }
    
    view View as select from
        Main,
        Target,
        Target as Duplicate
    {
        // This redirection can't be resolved:
        Main.toTarget : redirected to View
    };
    

    Entity Target exists more than once in View. In the previous example, this happens through the direct sources in the select clause. Because the original target exists twice in the redirected target, the compiler isn’t able to correctly resolve the redirection due to ambiguities.

    This can also happen through indirect sources. For example if entity Main were to include Target then selecting from Target just once would be enough to trigger this error.

    How to Fix

    To fix the issue, you must have the original target only once in your direct and indirect sources. The previous example can be fixed by removing Duplicate from the select clause.

    view View as select from Main, Target {
        Main.toTarget : redirected to View
    };
    

    If this isn’t feasible then you have to redefine the association using a mixin clause.

    view View as select from Main, Target mixin {
        toMain : Association to View on Main.id = Target.id;
    } into {
        Main.id   as mainId,
        Target.id as targetId,
        toMain
    };
    

    redirected-to-unrelated

    The redirected target doesn’t originate from the original target.

    The message’s severity is Error and is raised by the compiler. The error happens due to an ill-formed redirection, which requires changes to your model.

    Example

    Erroneous code example:

    entity Main {
        key id : Integer;
        // self association for example purpose only
        toMain : Association to Main;
    }
    entity Secondary {
        key id : Integer;
    }
    entity InvalidRedirect as projection on Main {
        id,
        // Invalid redirection
        toMain: redirected to Secondary,
    };
    

    Projection InvalidRedirect tries to redirect toMain to Secondary. However, that entity doesn’t have any connection to the original target Main, that means, it doesn’t originate from Main.

    While this example may be clear, your model may have multiple redirections that make the error not as obvious.

    Erroneous code example with multiple redirections:

    entity Main {
        key id : Integer;
        toMain : Association to Main;
    }
    entity FirstRedirect as projection on Main {
        id,
        toMain: redirected to FirstRedirect,
    }
    entity SecondRedirect as projection on FirstRedirect {
        id,
        // Invalid redirection
        toMain: redirected to Main,
    }
    

    The intent of the example above is to redirect toMain to its original target in SecondRedirect. But because SecondRedirect uses toMain from FirstRedirect, the original target is FirstRedirect. And Main doesn’t originate from FirstRedirect but only vice versa.

    How to Fix

    To fix the issue, you must redirect the association to an entity that originates from the original target. In the first example above you could redirect SecondRedirect:toMain to SecondRedirect. However, if that isn’t feasible then you have to redefine the association using a mixin clause.

    view SecondRedirect as select from FirstRedirect mixin {
        toMain : Association to Main on id = $self.id;
    } into {
        FirstRedirect.id as id,
        toMain
    };
    

    rewrite-not-supported

    The compiler isn’t able to rewrite ON conditions for some associations. They have to be explicitly defined by the user.

    The message’s severity is Error.

    Example

    Erroneous code example:

    entity Base {
      key id     : Integer;
      primary    : Association to Primary on primary.id = primary_id;
      primary_id : Integer;
    }
    
    entity Primary {
      key id       : Integer;
      secondary    : Association to Secondary on secondary.id = secondary_id;
      secondary_id : Integer;
    }
    
    entity Secondary {
      key id : Integer;
      text   : LargeString;
    }
    
    entity View as select from Base {
      id,
      primary.secondary // Error: The ON condition isn't rewritten here
    };
    

    In the previous example, the ON condition in View of secondary can’t be automatically rewritten because the associations are unmanaged and the compiler can’t determine how to properly rewrite them for View.

    How to Fix

    To fix the issue, you have to provide an explicit ON condition. This can be achieved by using the redirected to statement:

    entity View as select from Base {
      id,
      primary.secondary_id,
      primary.secondary: redirected to Secondary on
        secondary.id = secondary_id
    };
    

    In the corrected view above, the association secondary gets an explicit ON condition. For this to work it is necessary to add secondary_id to the selection list, that means, we have to explicitly use the foreign key.

    Show/Hide Beta Features