@sap/cds-compiler 3.1.0 → 3.3.2

package/share/messages/anno-duplicate-unrelated-layer.md

@@ -11,7 +11,7 @@ CDL file is equivalent to a layer.
 
 Erroneous code example using four CDS files:
 
-```cdl
+```cds
 // (1) Base.cds: Contains the artifact that should be annotated
 entity FooBar {  }
 
@@ -41,15 +41,15 @@ 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).
+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:
 
-```cdl
+```cds
 // (4) All.cds: Combine all files
 using from './FooAnnotate';
 using from './BarAnnotate';
@@ -60,7 +60,7 @@ 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.
 
-```cdl
+```cds
 // (3) BarAnnotate.cds: Now depends on (2)
 using from './FooAnnotate';
 annotate FooBar with @Anno: 'Bar';

package/share/messages/check-proper-type-of.md

@@ -4,13 +4,13 @@ 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).
+Otherwise, they aren’t able to render elements (for example, to SQL columns).
 
 ## Example
 
 Erroneous code example:
 
-```cdl
+```cds
 entity Foo {
   key id : Integer;
 };
@@ -33,9 +33,9 @@ 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`.
+Assign an explicit type to `ViewFoo:calculatedField`.
 
-```cdl
+```cds
 view ViewFoo as select from Foo {
   1+1 as calculatedField @(anno) : Integer
 };

package/share/messages/check-proper-type.md

@@ -27,8 +27,8 @@ Erroneous code example:
 
 ## How to Fix
 
-To fix the issue, add explicit type information to `MainType`, for example, add
-an `elements` property to make a structured type.
+Add explicit type information to `MainType`, for example, add an `elements`
+property to make a structured type.
 
 ```json
 {

package/share/messages/duplicate-autoexposed.md

@@ -15,7 +15,7 @@ adapt your model to fix the error.
 
 Erroneous code example:
 
-```cdl
+```cds
 // (1)
 entity ns.first.Foo {
   key parent : Association to one ns.Base;
@@ -46,13 +46,13 @@ 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.
+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`:
 
-```cdl
+```cds
   entity first.Foo as projection on ns.first.Foo;   // (5)
   entity second.Foo as projection on ns.second.Foo; // (6)
 ```

package/share/messages/extend-repeated-intralayer.md

@@ -11,7 +11,7 @@ They form a cyclic connection through their dependencies
 
 Erroneous code example with a single CDL file:
 
-```cdl
+```cds
 entity FooBar { }
 
 extend FooBar { foo : Integer; }
@@ -24,7 +24,7 @@ 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:
 
-```cdl
+```cds
 // (1) Definition.cds
 using from './Extension.cds';
 entity FooBar { };
@@ -40,10 +40,9 @@ 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:
+Move extensions for the same artifact into the same extension block:
 
-```cdl
+```cds
 // (1) Definition.cds : No extension block
 using from './Extension.cds';
 entity FooBar { }

package/share/messages/extend-unrelated-layer.md

@@ -11,7 +11,7 @@ They form a cyclic connection through their dependencies
 
 Erroneous code example using four CDS files:
 
-```cdl
+```cds
 // (1) Base.cds: Contains the artifact that should be extended
 entity FooBar {  }
 
@@ -38,13 +38,13 @@ 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.
+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):
 
-```cdl
+```cds
 // (2) FooExtend.cds
 using from './Base';
 extend FooBar {

package/share/messages/message-explanations.json

@@ -8,8 +8,10 @@
     "extend-repeated-intralayer",
     "extend-unrelated-layer",
     "redirected-to-ambiguous",
+    "redirected-to-complex",
     "redirected-to-unrelated",
     "rewrite-not-supported",
-    "syntax-expected-integer"
+    "syntax-expected-integer",
+    "wildcard-excluding-one"
   ]
 }

package/share/messages/redirected-to-ambiguous.md

@@ -11,7 +11,7 @@ your model.
 
 Erroneous code example:
 
-```cdl
+```cds
 entity Main {
       key id : Integer;
     toTarget : Association to Target;
@@ -42,11 +42,11 @@ 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.
+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.
 
-```cdl
+```cds
 view View as select from Main, Target {
     Main.toTarget : redirected to View
 };
@@ -55,7 +55,7 @@ view View as select from Main, Target {
 If this isn’t feasible then you have to redefine the association using a mixin
 clause.
 
-```cdl
+```cds
 view View as select from Main, Target mixin {
     toMain : Association to View on Main.id = Target.id;
 } into {
@@ -68,3 +68,4 @@ view View as select from Main, Target mixin {
 ## Related Messages
 
 - `redirected-to-unrelated`
+- `redirected-to-complex`

package/share/messages/redirected-to-complex.md

@@ -0,0 +1,63 @@
+# redirected-to-complex
+
+The redirected target is a complex view, for example, contains a JOIN or UNION.
+
+The message's severity is `Info` and is raised by the compiler.
+It is emitted to help developers identify possible modelling issues.
+
+## Example
+
+Erroneous code example:
+
+```cds
+entity Main {
+    key id : Integer;
+    // self association for example purpose only
+    toMain : Association to one Main;
+}
+entity Secondary {
+    content: String;
+};
+entity CrossJoin as SELECT from Main, Secondary;
+entity RedirectToComplex as projection on Main {
+    id,
+    toMain: redirected to CrossJoin,
+};
+```
+
+`Main:toMain` is a to-one association.  Since `Main` contains a single key,
+which is used in the managed association, we know that following the
+association returns a single result.
+
+The cross join in the view `CrossJoin` results in multiple rows with the same
+`id`.  Following the redirected view now returns multiple results, effectively
+making the to-one association a to-many association.
+
+Visualizing the tables with a bit of data, this issues becomes obvious:
+
+```markdown
+Main                        Secondary
+| id  | toMain_id |         | content |
+|-----|-----------|         |---------|
+| 1   | 2         |         | 'Hello' |
+| 2   | 1         |         | 'World' |
+
+CrossJoin
+| id  | toMain_id | content |
+|-----|-----------|---------|
+| 1   | 2         | 'Hello' |
+| 1   | 2         | 'World' |
+| 2   | 1         | 'Hello' |
+| 2   | 1         | 'World' |
+```
+
+## How to Fix
+
+Ensure that the redirected association points to an entity that is a reasonable
+redirection target.  You must ensure that the redirection does not accidentally
+result in a to-one association becoming a to-many association.
+
+## Related Messages
+
+- `redirected-to-ambiguous`
+- `redirected-to-unrelated`

package/share/messages/redirected-to-unrelated.md

@@ -10,7 +10,7 @@ your model.
 
 Erroneous code example:
 
-```cdl
+```cds
 entity Main {
     key id : Integer;
     // self association for example purpose only
@@ -35,7 +35,7 @@ that make the error not as obvious.
 
 Erroneous code example with multiple redirections:
 
-```cdl
+```cds
 entity Main {
     key id : Integer;
     toMain : Association to Main;
@@ -58,12 +58,12 @@ 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
+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.
 
-```cdl
+```cds
 view SecondRedirect as select from FirstRedirect mixin {
     toMain : Association to Main on id = $self.id;
 } into {
@@ -75,3 +75,4 @@ view SecondRedirect as select from FirstRedirect mixin {
 ## Related Messages
 
 - `redirected-to-ambiguous`
+- `redirected-to-complex`

package/share/messages/rewrite-not-supported.md

@@ -9,7 +9,7 @@ The message's severity is `Error`.
 
 Erroneous code example:
 
-```cdl
+```cds
 entity Base {
   key id     : Integer;
   primary    : Association to Primary on primary.id = primary_id;
@@ -39,10 +39,10 @@ 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:
+You have to provide an explicit ON condition.  This can be achieved by using
+the `redirected to` statement:
 
-```cdl
+```cds
 entity View as select from Base {
   id,
   primary.secondary_id,

package/share/messages/syntax-expected-integer.md

@@ -16,7 +16,7 @@ The message's severity is `Error`.
 Erroneous code example:
 
 <!-- cds-mode: ignore -->
-```cdl
+```cds
 type LengthIsUnsafe : String(9007199254740992);
 type NotAnInteger : String(42.1);
 ```
@@ -27,9 +27,9 @@ Likewise, the string length for the type `NotAnInteger` is a decimal.
 
 ## How to Fix
 
-To fix the issue, you have to provide a safe integer:
+You have to provide a safe integer:
 
-```cdl
+```cds
 type LengthIsSafe : String(9007199254740991);
 type AnInteger : String(42);
 ```

package/share/messages/wildcard-excluding-one.md

@@ -0,0 +1,37 @@
+# wildcard-excluding-one
+
+You're replacing an element in your projection, that is already included by
+using the wildcard `*`.
+
+The message's severity is `Info`.
+
+## Example
+
+Erroneous code example:
+
+```cds
+entity Book {
+  key  id : String;
+     isbn : String;
+  content : String;
+};
+entity IsbnBook as projection on Book {
+  *,
+  isbn as id,
+};
+```
+
+`IsbnBook:id` replaces `Book:id`, which was included in `IsbnBook` through
+the wildcard `*`.
+
+## How to Fix
+
+Add the replaced element to the list of wildcard excludes:
+
+```cds
+entity IsbnBook as projection on Book {
+  *,
+  isbn as id
+} excluding { id };
+```
+