Java: Views and Projections #1916
Conversation
|
Overall, LGTM. It is nice that we explain this stuff. |
| - [Path expressions](../../cds/cql#path-expressions) over compositions (*header.status*) are writable. For [Inserts](./query-api#insert), the view must expose all *not null* elements of the target entity and the data must include values for all of them. In the example above, the order header must have a generated key to support inserting new orders with a value for *headerStatus*. | ||
|
|
||
| ::: warning Path Expressions over Associations | ||
| Path expressions navigating *associations* (*header.customer.name*) are [not writable](#cascading-over-associations) by default. To avoid issues on write, annotate them with [@readonly](../../guides/providing-services#readonly). |
There was a problem hiding this comment.
This is explained earlier
For example, the following CDS model defines two resolvable views on the
Orderentity, which has a to-many items and a to-one header composition to a Header entity with a to-one customer association. In the projection, you can use path expressions as shown by headerStatus (writable) and customerName (read-only):
Why repeat it again?
There was a problem hiding this comment.
Above it's only a side note and since @readonly should be added, a box makes it clearer
| Do not use [*to-many associations*](../../cds/cdl#to-many-associations) in the select clause of CDS views. This blocks write operations and may cause performance issues due to record duplication on read. | ||
| ::: | ||
| ::: warning Avoid Composition Definitions in Views | ||
| Avoid [defining](../../cds/cql#association-definitions) new *compositions* in CDS views and prefer *associations* instead, as [deep write](#updatable-views) and [cascading delete](#delete-via-view) are only supported for compositions in persistence entities. |
There was a problem hiding this comment.
Isn't this true only for runtime views? I seen stakeholders who used such models and that surprisingly worked.
There was a problem hiding this comment.
This recommendation is for all views. On write there is not much of a difference between standard views and runtime views, as we need to resolve in both cases. Therefore the "write|delete through view" sections. Deep write/delete for such compositions needs to be implemented via custom logic.
|
|
||
|
|
||
| ::: tip Draft Queries on Runtime Views | ||
| If you define runtime views on [draft-enabled](../fiori-drafts#reading-drafts) entities and want to run draft specific queries on these views, set the *cds.drafts.persistence* configuration to `split`. |
There was a problem hiding this comment.
This should be "if you draft-enable runtime view", no? When I read this I always think about introducing projection on already draft-enabled projection.
I my projection is a runtime view and I want to draft-enable it, I have to use split persistence.
There was a problem hiding this comment.
Maybe also cross-reference http://localhost:5173/docs/java/fiori-drafts#reading-drafts
There was a problem hiding this comment.
This describes the case of defining a runtime view on an already draft-enabled entity.
From my understanding split mode is required for both cases and as of now, draft-enabling runtime views does not make much sense due to the draft table enforcing schema updates.
|
I like new structure a lot more! Apart from minors, I am OK with this. |
|
|
||
| #### Read in `CTE` mode { #rtview-cte } | ||
|
|
||
| This is the default mode in CAP Java `4.x`. The runtime translates the view definition into a _Common Table Expression_ (CTE) and sends it with the query to the database. |
There was a problem hiding this comment.
Love the new default! 😍
Co-authored-by: René Jeglinsky <[email protected]>
…into write-through-views
|
@BraunMatthias are you OK with this view docu change? |
|
|
||
| ### Write through Views { #updatable-views } | ||
|
|
||
| You can run [Insert](./query-api#insert), [Upsert](./query-api#upsert), and [Update](./query-api#update) statements on CDS views that are writable on the database or can be resolved to a single persistence entity by the CAP Java runtime. |
There was a problem hiding this comment.
| You can run [Insert](./query-api#insert), [Upsert](./query-api#upsert), and [Update](./query-api#update) statements on CDS views that are writable on the database or can be resolved to a single persistence entity by the CAP Java runtime. | |
| You can run [Insert](./query-api#insert), [Upsert](./query-api#upsert) and [Update](./query-api#update) statements on CDS views that are writable on the database or can be resolved to a single persistence entity by the CAP Java runtime. |
|
|
||
| The CDS compiler generates [DDL](../../guides/databases?impl-variant=java#generating-sql-ddl) files from your CDS model, including SQL views for the CDS views. These views are deployed to the [database](../cqn-services/persistence-services#database-support) and used by the CAP runtime to read data. | ||
|
|
||
| For *read-only* views, you can use the full feature set of [selects](../../cds/cdl#as-select-from), including *joins*, *unions*, and *aggregations*. However, such complex views are not writable and require a schema redeployment if the view definition is changed. |
There was a problem hiding this comment.
| For *read-only* views, you can use the full feature set of [selects](../../cds/cdl#as-select-from), including *joins*, *unions*, and *aggregations*. However, such complex views are not writable and require a schema redeployment if the view definition is changed. | |
| In addition, views that are used only for read access offer complex features to recombine data including *joins*, *unions*, and *aggregations*. However, be aware that such views enhanced with complex features **do not allow write queries and hence are restricted to read-only access**. Also such views always require schema redeployment if the view definition is changed. Read-only views support the full feature set of [selects](../../cds/cdl#as-select-from) to query data. | |
| ::: tip Prefer simple views | |
| Prefer creating simple views, each tailored to a specific use case, rather than a single complex view that tries to address multiple use cases simultaneously. | |
| ::: |
|
|
||
| Views and projections can be resolved if the following conditions are met: | ||
| ::: tip Prefer simple views |
Introduces "Views and Projections" section with
and documents some rules for write via path expressions in views.
Also shortens some headers to improve the readability in the navigation bar.