Definition Language (CDL)

    Find here a reference of all CDS concepts and features in the form of compact examples. The examples are given in CDL, a human-readable syntax for defining models, and CQL, an extension of SQL to write queries.

    Refer also to The Nature of Models and the CSN specification to complete your understanding of CDS.

    Entity and Type Definitions

    Entity Definitions — define entity

    Entities are structured types with named and typed elements, representing sets of (persisted) data that can be read and manipulated using usual CRUD operations. They usually contain one or more designated primary key elements:

    define entity Employees {
      key ID : Integer;
      name : String;
      jobTitle : String;

    The define keyword is optional, that means define entity Foo is equal to entity Foo.

    Type Definitions — define type

    You can declare custom types to reuse later on, for example, for elements in entity definitions. Custom-defined types can be simple, that is derived from one of the predefined types, structure types or Associations.

    define type User : String(111);
    define type Amount {
      value : Decimal(10,3);
      currency : Currency;
    define type Currency : Association to Currencies;

    The define keyword is optional, that means define type Foo is equal to type Foo.

    Learn more about Definitions of Named Aspects.

    Predefined Types

    See list of Built-in Types

    Structured Types

    You can declare and use custom struct types as follows:

    type Amount {
      value : Decimal(10,3);
      currency : Currency;
    entity Books {
      price : Amount;

    Elements can also be specified with anonymous inline struct types. For example, the following is equivalent to the definition of Books above:

    entity Books {
      price : {
        value : Decimal(10,3);
        currency : Currency;

    Arrayed Types

    Prefix a type specification with array of or many to signify array types.

    entity Foo { emails: many String; }
    entity Bar { emails: many { kind:String; address:String; }; }
    entity Car { emails: many EmailAddress; }
    entity Car { emails: EmailAddresses; }
    type EmailAddresses : many { kind:String; address:String; }
    type EmailAddress : { kind:String; address:String; }

    Keywords many and array of are mere syntax variants with identical semantics and implementations.

    When deployed to SQL databases, such fields are mapped to LargeString columns and the data is stored denormalized as JSON array. With OData V4, arrayed types are rendered as Collection in the EDM(X).

    Filter expressions, instance-based authorization and search are not supported on arrayed elements.

    Null Values

    For arrayed types the null and not null constraints apply to the members of the collections. The default is not null indicating that the collections can’t hold null values.

    An empty collection is represented by an empty JSON array. A null value is invalid for an element with arrayed type.

    In the following example the collection emails may hold members that are null. It may also hold a member where the element kind is null. The collection email must not be null!

    entity Bar {
        emails      : many {
            kind    : String null;
            address : String not null;
        } null;

    Virtual Elements

    An element definition can be prefixed with modifier keyword virtual. This keyword indicates that this element isn’t added to persistent artifacts, that is, tables or views in SQL databases. Virtual elements are part of OData metadata.

    By default virtual elements are annotated with @Core.Computed: true, not writable for the client and will be silently ignored. This means also, that they are not accessible in custom event handlers. If you want to make virtual elements writable for the client, you explicitly need to annotate these elements with @Core.Computed: false.

    entity Employees {
      virtual something : String(11);


    Using literals in CDS models is commonly used, for example, to set default values. The literals in the following table show you how to define these values in your CDS source.

    Kind Example
    Null null
    Boolean true, false
    Numbers 11, 2.4, or 1.34e10
    Strings 'foo'
    Dates date'2016-11-24'
    Times time'16:11:32'
    Timestamp timestamp'2016-11-24 16:11:32.4209753'
    DateTimes '2016-11-24T16:11'
    Records {"foo":<literal>, ...}
    Arrays [<literal>, ...]

    Learn more about literals and their representation in CSN.

    Delimited Identifiers

    Delimited identifiers allow you to use any identifier, even containing special characters or using a keyword.

    Special characters in identifiers or keywords as identifiers should be avoided for best interoperability.

    entity ![Entity] {
      bar           : ![Keyword];
      ![with space] : Integer;

    Default Values

    As in SQL you can specify default values to fill in upon INSERTs if no value is specified for a given element.

    entity Foo {
      bar : String default 'bar';
      boo : Integer default 1;

    Type References

    If you want to base an element’s type on another element of the same structure, you can use the type of operator.

    entity Author {
      firstname : String(100);
       lastname : type of firstname; // has type "String(100)"

    For referencing elements of other artifacts, you can use the element access through :. Element references with : don’t require type of in front of them.

    entity Employees {
      firstname: type of Author:firstname;
       lastname: Author:firstname; // optional 'type of'


    Element definitions can be augmented with constraint not null as known from SQL.

    entity Employees {
      name : String(111) not null;


    You can specify enumeration values for a type as a semicolon-delimited list of symbols. For string types, declaration of actual values is optional; if omitted, the actual values are the string counterparts of the symbols.

    type Gender : String enum { male; female; }
    entity Order {
      status : Integer enum {
        submitted =  1;
        fulfilled =  2;
        shipped   =  3;
        canceled  = -1;

    To enforce your enum values during runtime, use the @assert.range annotation.

    Views and Projections

    Use as select from or as projection on to derive new entities from existing ones by projections, very much like views in SQL. When mapped to relational databases, such entities are in fact translated to SQL views but they’re frequently also used to declare projections without any SQL views involved.

    The entity signature is inferred from the projection.

    The as select from Variant

    Use the as select from variant to use all possible features an underlying relational database would support using any valid CQL query including all query clauses.

    entity Foo1 as SELECT from Bar; //> implicit {*}
    entity Foo2 as SELECT from Employees { * };
    entity Foo3 as SELECT from Employees LEFT JOIN Bar on Employees.ID=Bar.ID {
      foo, bar as car, sum(boo) as moo
    } where exists (
      SELECT 1 as anyXY from SomeOtherEntity as soe where soe.x = y
    group by foo, bar
    order by moo asc;

    The as projection on Variant

    Use the as projection on variant instead of as select from to indicate that you don’t use the full power of SQL in your query. For example, having a restricted query in an entity allows us to serve such an entity from external OData services.

    entity Foo as projection on Bar {...}

    Currently the restrictions of as projection on compared to as select from are:

    • no explicit, manual JOINs
    • no explicit, manual UNIONs
    • no sub selects in from clauses

    Over time, we can add additional checks depending on specific outbound protocols.

    Views with Inferred Signatures

    By default views inherit all properties and annotations from their primary underlying base entity. Their elements signature is inferred from the projection on base elements. Each element inherits all properties from the respective base element.

    For example, the following definition:

    entity SomeView as SELECT from Employees {
      job.title as jobTitle

    Might result in this inferred signature:

    entity SomeView {
      ID: Integer;
      name: String;
      jobTitle: String;

    If you don’t want to use the inferred type, you can change the element’s type by using a CDL cast:

    entity SomeView as SELECT from Employees {
      ID : Integer64,
      name : LargeString

    By using a cast, neither annotations nor other properties are propagated, see Annotation Propagation

    Views with Parameters

    You can equip views with parameters that are passed in whenever that view is queried. Default values can be specified. Refer to these parameters in the view’s query using the prefix :.

    entity SomeView ( foo: Integer, bar: Boolean )
    as SELECT * from Employees where ID=:foo;

    Learn more about how to expose views with parameters in Services - Exposed Entities. Learn more about views with parameters for existing HANA artifactsSee in Native SAP HANA Artifacts.

    Associations & Compositions

    Associations capture relationships between entities. They are like forward-declared joins added to a table definition in SQL.

    Unmanaged Associations

    Unmanaged associations specify arbitrary join conditions in their on clause, which refer to available foreign key elements. The association’s name (address in the following example) is used as the alias for the to-be-joined target entity.

    entity Employees {
      address : Association to Addresses on address.ID = address_ID;
      address_ID : Integer;  //> foreign key
    entity Addresses {
      key ID : Integer;

    Managed (To-One) Associations

    For to-one associations, CDS can automatically resolve and add requisite foreign key elements from the target’s primary keys and implicitly add respective join conditions.

    entity Employees {
      address : Association to Addresses;

    This example is equivalent to the unmanaged example above, with the foreign key element address_ID being added automatically upon activation to a SQL database.

    No foreign key constraints are added on database level.

    To-many Associations

    For to-many associations specify an on condition following the canonical expression pattern <assoc>.<backlink> = $self as in this example:

    entity Employees {
      key ID : Integer;
      addresses : Association to many Addresses
        on addresses.owner = $self;
    entity Addresses {
      owner : Association to Employees;  //> the backlink

    The backlink can be any managed to-one association on the many side pointing back to the one side.

    Many-to-many Associations

    For many-to-many association, follow the common practice of resolving logical many-to-many relationships into two one-to-many associations using a link entity to connect both. For example:

    entity Employees { ...
      addresses : Association to many Emp2Addr on addresses.emp = $self;
    entity Emp2Addr {
      key emp : Association to Employees;
      key adr : Association to Addresses;

    Learn more about Managed Compositions for Many-to-many Relationships.


    Compositions constitute document structures through ‘contained-in’ relationships. They frequently show up in to-many header-child scenarios.

    entity Orders {
      key ID: Integer; //...
      Items : Composition of many Orders.Items on Items.parent = $self;
    entity Orders.Items {
      key pos : Integer;
      key parent : Association to Orders;
      product : Association to Products;
      quantity : Integer;

    Essentially, Compositions are the same as associations, just with the additional information that this association represents a contained-in relationship so the same syntax and rules apply in their base form.

    Managed Compositions of Aspects

    Use managed compositions variant to nicely reflect document structures in your domain models, without the need for separate entities, reverse associations, and unmanaged on conditions.

    With Inline Targets

    entity Orders { 
      key ID: Integer; //...
      Items : Composition of many { 
        key pos : Integer;
        product : Association to Products;
        quantity : Integer;

    Managed Compositions are mostly syntactical sugar: Behind the scenes, they are unfolded to the unmanaged equivalent as shown above by automatically adding a new entity, the name of which being constructed as a scoped name from the name of parent entity, followed by the name of the composition element, that is Orders.Items in the previous example. You can safely use this name at other places, for example to define an association to the generated child entity:

      specialItem : Association to Orders.Items;

    With Named Targets

    Instead of anonymous target aspects you can also specify named aspects, which are unfolded the same way as anonymous inner types, as shown in the previous example:

    entity Orders {
      key ID: Integer; //...
      Items : Composition of many OrderItems;
    aspect OrderItems { 
      key pos : Integer;
      product : Association to Products;
      quantity : Integer;

    For Many-to-many Relationships

    Managed Compositions are handy for many-to-many relationships, where a link table usually is private to one side.

    entity Teams { ...
      members : Composition of many { key user: Association to Users; }
    entity Users { ...
      teams: Association to many Teams.members on teams.user = $self;

    And here’s an example of an attributed many-to-many relationship:

    entity Teams { ...
      members : Composition of many {
        key user : Association to Users;
        role : String enum { Lead; Member; Collaborator; }
    entity Users { ... }

    To navigate between Teams and Users, you have to follow two associations: members.user or teams.up_. In OData, use a query like:

    GET /Teams?$expand=members($expand=user)

    to get all users of all teams.


    This section describes how to add Annotations to model definitions written in CDL, focused on the common syntax options, and fundamental concepts. Find additional information in the OData Annotations guide.

    Annotation Syntax

    Annotations in CDL are prefixed with an @ character and can be placed before a definition, after the defined name or at the end of simple definitions.

    @before entity Foo @inner {
      @before simpleElement @inner : String @after;
      @before structElement @inner { /* elements */ }

    Multiple annotations can be placed in each spot separated by whitespaces or enclosed in @(...) and separated by comma - like the following are equivalent:

    entity Foo @(
      my.annotation: foo, 4711
    ) { /* elements */ }
    @my.annotation:foo 4711
    entity Foo { /* elements */ }

    For an @inner annotation, only the syntax @(...) is available.

    Annotation Targets

    You can basically annotate any named thing in a CDS model, such as:

    Contexts and services:

    @before [define] (context|service) Foo @inner { ... }

    Definitions and elements with simple types:

    @before [define] type Foo @inner : String @after;
    @before [key] anElement @inner : String @after;

    Entities, aspects, and other struct types and elements thereof:

    @before [define] (entity|type|aspect|annotation) Foo @inner {
      @before simple @inner : String @after;
      @before struct @inner { ...elements... };


    ... status : String @inner enum {
      fulfilled @after;

    Columns in a view definition’s query:

    ... as SELECT from Foo {
      @before expr as alias @inner : String,

    Parameters in view definitions:

    ... with parameters (
      @before param @inner : String @after
    ) ...

    Actions/functions including their parameters and result elements:

    @before action doSomething @inner (
      @before param @inner : String @after
    ) returns {
      @before result @inner : String @after;

    Annotation Values

    Values can be literals or references. If no value is given, the default value is true as for @aFlag in the following example:

    @aFlag //= true, if no value is given
    @aBoolean: false
    @aString: 'foo'
    @anInteger: 11
    @aDecimal: 11.1
    @aSymbol: #foo
    @anArray: [ /* can contain any kind of value */ ]

    As described in the CSN spec, the previously mentioned annotations would compile to CSN as follows:

      "@aFlag": true,
      "@aBoolean": false,
      "@aString": "foo",
      "@anInteger": 11,
      "@aDecimal": 11.1,
      "@aSymbol": {"#":"foo"},
      "@aReference": {"=":""},
      "@anArray": [ ... ]

    References (and expressions in general) aren’t checked or resolved by CDS parsers or linkers. They’re interpreted and evaluated only on consumption-specific modules. For example, for SAP Fiori models, it’s the 4odata and 2edm(x) processors.

    Records as Syntax Shortcuts

    Annotations in CDS are flat lists of key-value pairs assigned to a target. The record syntax - that is, {key:<value>, ...} - is a shortcut notation that applies a common prefix to nested annotations. For example, the following are equivalent: 'wheels'
    @Common: {, 'wheels' } { bar } 'wheels' { bar, car: 'wheels'  }

    and they would show up as follows in a parsed model (→ see CSN):

      "": true,
      "": "wheels",

    Annotation Propagation

    Annotations are inherited from types and base types to derived types, entities, and elements as well as from elements of underlying entities in case of views.

    For examples, given this view definition:

    using Books from './bookshop-model';
    entity BooksList as SELECT from Books {
      ID, genre : Genre, title, as author
    • BooksList would inherit annotations from Books
    • BooksList.ID would inherit from Books.ID
    • would inherit from
    • BooksList.genre would inherit from type Genre

    The rules are:

    1. Entity-level properties and annotations are inherited from the primary underlying source entity — here Books.

    2. Each element that can unambiguously be traced back to a single source element, inherits that element’s properties.

    3. An explicit cast in the select clause cuts off the inheritance, for example, as for genre in our previous example.

    The annotate Directive

    The annotate directive allows to annotate already existing definitions, that may have been imported from other files or projects.

    annotate Foo with @title:'Foo' {
      nestedStructField {
        existingField @title:'Nested Field';
    annotate Bar with @title:'Bar';

    The annotate directive is a variant of the extend directive. Actually, annotate is just a shortcut with the default mode being switched to extending existing fields instead of adding new ones.

    Extend Array Annotations

    Usually the annotation value provided in an annotate directive overwrites an already existing annotation value.

    If the existing value is an array:

    @anArray: [3, 4] entity Foo { /* elements */ }

    the ellipsis syntax allows to insert new values before or after the existing entries, instead of overwriting the complete array:

    annotate Foo with @anArray: [1, 2, ...];  //> prepend new values: [1, 2, 3, 4]
    annotate Foo with @anArray: [..., 5, 6];  //> append new values: [3, 4, 5, 6]
    annotate Foo with @anArray: [1, 2, ..., 5, 6]; //> prepend and append

    The ellipsis represents the already existing array entries. Of course, this works with any kind of array entries.


    CDS’s aspects allow to flexibly extend definitions by new elements as well as overriding properties and annotations. They’re based on a mixin approach as known from Aspect-oriented Programming methods.

    The extend Directive

    Use extend to add extension fields or to add/override metadata to existing definitions, for example, annotations, as follows:

    extend Foo with @title:'Foo' {
      newField : String;
      extend nestedStructField {
        newField : String;
        extend existingField @title:'Nested Field';
    extend Bar with @title:'Bar'; // nothing for elements

    Make sure that you prepend the extend keyword to nested elements, otherwise this would mean that you want to add a new field with that name:

    Learn more about the annotate Directive.

    Named Aspects — define aspect

    You can use extend or annotate with predefined aspects, to apply the same extensions to multiple targets:

    extend Foo with ManagedObject;
    extend Bar with ManagedObject;
    aspect ManagedObject {
      created { at: Timestamp; _by: User; }

    The define keyword is optional, that means define aspect Foo is equal to aspect Foo.

    If you use extend, all nested fields in the named aspect are interpreted as being extension fields. If you use annotate, the nested fields are interpreted as existing fields and the annotations are copied to the corresponding target elements.

    The named extension can be anything, for example, including other types or entities. Use keyword aspect as shown in the example to declare definitions that are only meant to be used in such extensions, not as types for elements.

    Includes – : as Shortcut Syntax

    You can use an inheritance-like syntax option to extend a definition with one or more named aspects as follows:

    define entity Foo : ManagedObject, AnotherAspect {
      key ID : Integer;
      name : String;

    This is syntactical sugar and equivalent to using a sequence of extends as follows:

    define entity Foo {}
    extend Foo with ManagedObject;
    extend Foo with AnotherAspect;
    extend Foo with {
      key ID : Integer;
      name : String;

    You can apply this to any definition of an entity or a structured type.

    Looks Like Inheritance

    The :-based syntax option described before looks very much like (multiple) inheritance and in fact has very much the same effects. Yet, as mentioned in the beginning of this section, it isn’t based on inheritance but on mixins, which are more powerful and also avoid common problems like the infamous diamond shapes in type derivations.

    When combined with persistence mapping there are a few things to note, that goes down to which strategy to choose to map inheritance to, for example, relational models. See Aspects vs Inheritance for more details.

    Extending Views and Projections

    Use the extend projection variant to extend the projection of a view entity to include more elements existing in the underlying entity:

    extend projection Foo with @title:'Foo' {
      foo as bar @car

    Enhancing nested structs isn’t supported. Note also that you can use the common annotate syntax, to just add/override annotations of a view’s elements.


    Service Definitions

    CDS allows to define service interfaces as collections of exposed entities enclosed in a service block, which essentially is and acts the same as context:

    service SomeService {
      entity SomeExposedEntity { ... };
      entity AnotherExposedEntity { ... };

    The endpoint of the exposed service is constructed by its name, following some conventions (the string service is dropped and kebab-case is enforced). If you want to overwrite the path, you can add the @path annotation as follows:

    @path: 'myCustomServicePath'
    service SomeService { ... }

    Exposed Entities

    The entities exposed by a service are most frequently projections on entities from underlying data models. Standard view definitions, using as SELECT from or as projection on, can be used for exposing entities.

    service CatalogService {
      entity Product as projection on data.Products {
        *, as since
      } excluding { created };
    service MyOrders {
      //> $user only implemented for SAP HANA
      entity Order as select from data.Orders { * } where buyer=$;
      entity Product as projection on CatalogService.Product;

    You can optionally add annotations such as @readonly or @insertonly to exposed entities, which, will be enforced by the CAP runtimes in Java and Node.js.

    Entities can be also exposed as views with parameters:

    service MyOrders {
      entity OrderWithParameter( foo: Integer ) as select from data.Orders where id=:foo;

    A view with parameter modeled in the previous example, can be exposed as follows:

    service SomeService {
      entity ViewInService( p1: Integer, p2: Boolean ) as select from data.SomeView(foo: :p1, bar: :p2) {*};

    Then the OData request for views with parameters should look like this:

    GET: /OrderWithParameter(foo=5)/Set or GET: /OrderWithParameter(5)/Set
    GET: /ViewInService(p1=5, p2=true)/Set

    (Auto-) Redirected Associations

    When exposing related entities, associations are automatically redirected. This ensures that clients can navigate between projected entities as expected. For example:

    service AdminService {
      entity Books as projection on my.Books;
      entity Authors as projection on my.Authors;
      //> AdminService.Authors.books refers to AdminService.Books

    Resolving Ambiguities

    Auto-redirection fails if a target can’t be resolved unambiguously, that is, when there is more than one projection with the same minimal ‘distance’ to the source. For example, compiling the following model with two projections on my.Books would produce this error:

    Target “Books” is exposed in service “AdminService” by multiple projections “AdminService.ListOfBooks”, “AdminService.Books” - no implicit redirection.

    service AdminService {
      entity ListOfBooks as projection on my.Books;
      entity Books as projection on my.Books;
      entity Authors as projection on my.Authors;
      //> which one should AdminService.Authors.books refers to?

    Using redirected to with Projected Associations

    You can use redirected to to resolve the ambiguity as follows:

    service AdminService {
      entity Authors as projection on my.Authors { *,
        books : redirected to Books //> resolved ambiguity

    Using Annotations

    Alternatively, you can use the boolean annotation with value true to make an entity a preferred redirection target, or with value false to exclude an entity as target for auto-redirection.

    service AdminService { true
      entity ListOfBooks as projection on my.Books;

    Auto-Exposed Entities

    Annotate entities with @cds.autoexpose to automatically expose them in services containing entities with associations referring to them.

    For example, given the following entity definitions:

    // schema.cds
    namespace schema;
    entity Bar @cds.autoexpose { key id: Integer; }
    using { sap.common.CodeList } from '@sap/cds/common';
    entity Car : CodeList { key code: Integer; }
    //> inherits  @cds.autoexpose from  sap.common.CodeList

    … a service definition like this:

    using { schema as my } from './schema.cds';
    service Zoo {
      entity Foo { //...
        bar : Association to my.Bar;
        car : Association to my.Car;

    … would result in the service being automatically extended like this:

    extend service Zoo with { // auto-exposed entities:
       @readonly entity Foo_bar as projection on Bar;
       @readonly entity Foo_car as projection on Car;

    You can still expose such entities explicitly, for example, to make them read-write:

    service Sue {
      entity Foo { /*...*/ }
      entity Bar as projection on my.Bar;

    Learn more about CodeLists in @sap/cds/common.

    Custom Actions and Functions

    Within service definitions, you can additionally specify actions and functions. Use a comma-separated list of named and typed inbound parameters and an optional response type, which can be either a:

    service MyOrders {
      entity Order { /*...*/ };
      // unbound actions / functions
      type cancelOrderRet {
        acknowledge: String enum { succeeded; failed; };
        message: String;
      action cancelOrder ( orderID:Integer, reason:String ) returns cancelOrderRet;
      function countOrders() returns Integer;
      function getOpenOrders() returns array of Order;

    The notion of actions and functions in CDS adopts that of OData; actions and functions on service-level are unbound ones.

    Bound Actions and Functions

    Actions and functions can also be bound to individual entities of a service, enclosed in an additional actions block as the last clause in an entity/view definition.

    service CatalogService {
      entity Products as projection on data.Products { ... }
        actions {
          // bound actions/functions
          action addRating (stars: Integer);
          function getViewsCount() returns Integer;

    Custom-Defined Events

    Similar to Actions and Functions you can declare events, which a service emits via messaging channels. Essentially, an event declaration looks very much like a type definition, specifying the event’s name and the type structure of the event messages’ payload.

    service MyOrders { ...
      event OrderCanceled {
        orderID: Integer;
        reason: String;

    Extending Services

    You can extend services with additional entities and actions much as you would add new entities to a context:

    extend service CatalogService with {
      entity Foo {};
      function getRatings() returns Integer;

    Similarly, you can extend entities with additional actions as you would add new elements:

    extend entity CatalogService.Products with actions {
      function getRatings() returns Integer;


    The namespace Directive

    To prefix the names of all subsequent definitions, place a namespace directive at the top of a model. This is comparable to other languages, like Java.


    entity Foo {}           //> 
    entity Bar : Foo {}     //>

    The context Directive

    Use contexts for nested namespace sections.


    entity Foo {}           //>
    context scoped {
      entity Bar : Foo {}   //>
      context nested {
        entity Zoo {}       //>

    Scoped Definitions

    You can define types and entities with other definitions’ names as prefixes:

    entity Foo {}           //>
    entity Foo.Bar {}       //>
    type Foo.Bar.Car {}     //>

    Fully Qualified Names

    A model ultimately is a collection of definitions with unique, fully qualified names. For example, the second model above would compile to this CSN:


      "": { "kind": "entity" },
      "": { "kind": "context" },
      "": { "kind": "entity",
        "includes": [ "" ]
      "": { "kind": "context" },
      "": { "kind": "entity" }

    Import Directives

    The using Directive

    Using directives allows to import definitions from other CDS models. As shown in line three below you can specify aliases to be used subsequently. You can import single definitions as well as several ones with a common namespace prefix. Optional: Choose a local alias.


    using from './contexts';
    using from './contexts';
    using as specified from './contexts';
    entity Car : Bar {}            //> : 
    entity Moo : nested.Zoo {}     //> :
    entity Zoo : specified.Zoo {}  //> :

    Multiple named imports through es6-like deconstructors:

    using { Foo as Moo, sub.Bar } from './base-model';
    entity Boo : Moo { /*...*/ }
    entity Car : Bar { /*...*/ }

    Also in the deconstructor variant of using shown in the previous example, specify fully qualified names.

    Model Resolution

    Imports in cds work very much like require in node and imports in ES6. In fact, we reuse Node’s module loading mechanisms. Hence, the same rules apply:

    • Relative path resolution
      Names starting with ./ or ../ are resolved relative to the current model.
    • Resolving absolute references
      They’re fetched for in node_modules folders:
      • Files having .cds, .csn, or .json as suffixes, appended in order
      • Folders, from either the file set in cds.main in the folder’s package.json or index.<cds|csn|json> file.

    To allow for loading from precompiled .json files it’s recommended to omit .cds suffixes in import statements, as shown in the provided examples.


    Single-Line Comments — //

    Any text between // and the end of the line is ignored:

    entity Employees {
      key ID : Integer;  // a single-line comment
      name : String;

    Multi-Line Comments — /* */

    Any text between /* and */ is ignored:

    entity Employees {
      key ID : Integer;
      a multi-line comment
      name : String;

    unless it is a doc comment.

    Doc Comments — /** */

    A multi-line comment of the form /** */ at an annotation position is considered a doc comment:

     * I am the description for "Employee"
    entity Employees {
      key ID : Integer;
       * I am the description for "name"
      name : String;

    The text of a doc comment is stored in CSN in the property doc. When generating OData EDM(X), it appears as value for the annotation @Core.Description.

    When generating output for deployment to SAP HANA, the first paragraph of a doc comment is translated to the HANA COMMENT feature for tables, table columns, and for views (but not for view columns):

    CREATE TABLE Employees (
      name NVARCHAR(...) COMMENT 'I am the description for "name"'
    ) COMMENT 'I am the description for "Employee"'

    Doc comments need to be switched on when calling the compiler:

    # in CLI:
    cds compile foo.cds --docs
    // in JavaScript:
    cds.compile(..., { docs: true })
    Show/Hide Beta Features