cap-js/cds-dbs

@cap-js/sqlite virtual fields leads to OoM exception in browsers

T1mey opened this issue · 5 comments

T1mey commented

Hello all,

when using a virtual field in combination with sqlite my fiori elements UI does not respond anymore and after some time there is an OoM exception reported.

image

"@sap/cds": "^7.5.1",
"@cap-js/sqlite": "^1.4.0",

johannes-vogel commented

Please share more insights on your issue.
Best case, you provide a minimal sample for reproduction :)
Otherwise, we're not able to help.

somabagyinszky7 commented

Hi there,
I'm having the same issue as described above.

My findings

I investigated the problem and found that the virtual property is missing from the objects returned by the query result.
This causes the Fiori elements front-end to erratically re-request the property resulting in a lot of errors resulting in the aforementioned OoM problem:

Failed to drill-down into (ID=710e755b-2ab2-4563-9abe-496e9675add0,IsActiveEntity=false)/virtualProp, invalid segment: virtualProp - odata/v4/demo/SomeEntities(ID=361c019f-e53c-43d2-8d77-3a38ed1dc12c,IsActiveEntity=false)/someRelation?$count=true&$select=HasActiveEntity,ID,IsActiveEntity,prop1,prop2,virtualProp,prop3&$expand=someRelation($select=prop4,prop5) sap.ui.model.odata.v4.lib._Cache

Findings in backend

I also investigated the problem in the backend. The problem happens for me on READ events.
I found that query results don't include the virtual property and thus are not returned to the front end.
Upon investigating @sap/cds/lib/srv/srv-dispatch.js I wasn't able to find a method / registered handler executing for handling virtual properties.
Before, there was a handler registered to special handle these properties in node_modules/@sap/cds/libx/_runtime/db/generic/virtual.js:73. (I believe I'm unable to link this better since this repository is privately hosted, so please excuse this.)
However, when using the new implementation this handler is not executed as these modules are replaced by the new ones under @cap-js/dbs.
I wasn't able to locate anything handling this in the new modules.

Questions

Is this a bug? Or are these not handled on purpose anymore? It would make sense to me not to include this on the database service level, but rather somewhere on a higher level, however, I'm not that familiar with the code base.

To Reproduce

Please find my example repo here to reproduce the issue:
https://github.com/somabagyinszky7/cap-virtual-properties

Steps:

  • Start the project with cds watch.
  • Create a new entity instance in the table.

Workaround

@T1mey For me it was enough, for now, to define in my afterRead handler an else case which sets a 'default' value for the virtual property.

async function afterReadHandler(someResults) {
    return someResults.forEach((someResult) => {
      if (someResult["someProp"]) {
        someResult.virtualProp = "value";
      } else {
        someResult.virtualProp = "defaultValue";
      }
    });
  }
patricebender commented

Is this a bug? Or are these not handled on purpose anymore? It would make sense to me not to include this on the database service level, but rather somewhere on a higher level, however, I'm not that familiar with the code base.

This is correct, to quote from capire:

In contrast to their former behaviour, new database services ignore all virtual elements and hence don't add them to result set entries. Selecting only virtual elements in a query leads to an error.

maybe @johannes-vogel can add up on that

  • 👍1
somabagyinszky7 commented

Thanks for clearing it up!

patricebender commented

This causes the Fiori elements front-end to erratically re-request the property resulting in a lot of errors resulting in the aforementioned OoM problem:

I would say our library behaves as expected and this is more an issue with the re-occuring request that eventually lead to the OOM exception. I will close this issue as we don't see how we can improve the situation.

  • 👍1