Refactored Event Queues

We introduced optimized scheduling by default (cds.requires.scheduling=true). This is only relevant in case projects used the in-memory queue or need to opt-out of certain event queues configs.

Queue kind in-memory-queue is deprecated and not supported if optimized scheduling is enabled.

We streamlined the event queues config options:

• Sources:
  • cds.requires.outbox is deprecated. Use cds.requires.queue instead.
  • cds.requires.<srv>.outbox is deprecated. Use cds.requires.<srv>.outboxed instead.
• Options:
  • cds.requires.queue.legacyLocking is now false by default
  • cds.requires.queue.storeLastError was removed (now always true implicitly)
  • cds.requires.queue.maxAttempts is now 10 by default
  • Inofficial cds.requires.queue.targetPrefix is deprecated. Use cds.appid instead.

Are you affected?

• check for in-memory-queue in all cds env input files
• check for requires.outbox in all cds env input files
• check for outbox in a requires entry in all cds env input files (e.g., requires.API_BUSINESS_PARTNER.outbox)
• legacyLocking: check if cds^9 is being skipped, i.e., upgrading from cds^8 directly to cds^10
• check for storeLastError in all cds env input files
• check for targetPrefix in all cds env input files

How to address?

• in-memory-queue: Switch to default persistent-queue (i.e., remove the config).
• legacyLocking: In case of skipping cds^9 and utilizing blue-green deployments, projects should set cds.requires.queue.legacyLocking=true and cds.requires.scheduling=false for deployment and then remove both configs again.

Removed Transitive Localized Views

Since cds-compiler v5, the compiler doesn't any longer generate so-called "transitive localized views" by default, because they are no longer used by the runtimes. See Release notes June 2024.

Before cds-compiler v7, it was possible to switch them back on with configuration cds.sql.transitive_localized_views (see Deprecated Features).

With cds-compiler v7, this configuration option has been removed. There is no possibility to generate transitive localized views any longer. These views will disappear with the next database migration. As proven by multiple stakeholders and customers during the grace period of >2 years, that is transparent, and non breaking to applications.

Removed odata_metadata_compat

• we removed the legacy compat flag cds.features.odata_metadata_compat completely.

Are you affected?

• check if flag cds.features.odata_metadata_compat=true is set in any of cds config files (package.json, cdsrc.json, cdsrc.yml, cdsrc.js)

How to address?

• You have to adapt your implementation.
• Check that no handlers are registered for getCsn calls of the ModelProviderService

Removed async_handler_compat

• we removed the legacy compat flag cds.features.async_handler_compat completely.

Are you affected?

• check if flag cds.features.async_handler_compat=true is set in any of cds config files (package.json, cdsrc.json, cdsrc.yml, cdsrc.js)

How to address?

• You have to adapt your implementation.
• do not depend on order of handler execution in before phase
• ensure that the custom handlers cannot be influenced through asynchronous processing

Removed deploy format hdbcds

• we removed the support for deploy format hdbcds

Are you affected?

• check for "deploy-format": "hdbcds" in cds config files (double check!)
• check for cds.compile.to.hdbcds calls in js code

How to address?

• Use the default deploy format .hdbtable instead. It can also be programmatically called with cds.compile.to.hdbtable
• see also May 25
• Note that the format is different. check the documentation for migration

compat_save_drafts

• we removed the legacy compat flag cds.features.compat_save_drafts completely.

Are you affected?

• check if flag cds.features.compat_save_drafts=true is set in any of cds config files (package.json, cdsrc.json, cdsrc.yml, cdsrc.js)

How to address?

• Instead of registering handlers for the SAVE event on <entity>.drafts, register it on the events ['CREATE', 'UPDATE']

API cds.User.tokenInfo

• the undocumented API is now removed, but there is a successor.

Are you affected?

• check if user.tokenInfo occurs in js files

How to address?

• instead of cds.context.user.tokenInfo use cds.context.user.authInfo.token
• inside a custom handler: instead of use req.user.tokenInfo use req.user.authInfo.token
• also see Aug 25

API cds.context.http.req.authInfo

• the undocumented API is now removed, but there is a successor.

Are you affected?

• check if req.authInfo occurs in js files

How to address?

• instead of cds.context.http.req.authInfo use cds.context.user.authInfo
• inside a custom handler: instead of use req.http.req.authInfo use req.user.authInfo
• also see Aug 25

Removed cds-plugin.js activate() function

Removed support for async activate() functions returned from cds-plugin.js modules, which was never documented, and deprecated since Oct 2023. -> If you need to run async code during plugin loading, just return a promise as default export.

CDS Vocabulary change for Common.SideEffectsType

cds-compiler v7 contains an update of the OData vocabulary Common, where the complex type Common.SideEffectsType was changed incompatibly: the property EffectsType was removed. This property was already marked as deprecated, and no client makes use of it.

If you use this property in a @Common.SideEffects annotation, the compiler still renders it to the OData Edmx, but due to (now) lacking vocabulary information with a wrong type. As clients don't use this property, this has no negative impact.

Are you affected?

With cds-compiler v7, there is a compiler warning:

Warning[odata-anno-type]: “EffectTypes” is not a known property for “@Common.SideEffects” of type “Common.SideEffectsType”

No negative impact on your project is expected.

How to address?

(optional) For the sake of clean models, we recommend to remove the unnecessary property EffectsType from your @Common.SideEffects annotations in your CDS models.

 @Common.SideEffects: {
  // ...
  EffectTypes : #ValueChange,  // <-- obsolete, remove it
  // ...
}