cap-js
[FEATURE] Consumption of parameterized views
Description
As far as I am aware there does not seem to be a nice and typed way for consumption of parameterized views. In fact it seems that view parameters are not considered at all at this point.
At the moment, to consume I need to write similar to this:
const libraryId = '1234';
const books = await SELECT.from(`${Books.name}(libraryId:'${libraryId}')`) as Book[];
This is of course not a very sensible example for the use of parameterized views.
Suggested Solution
I honestly am not sure what the best way to depict this would be. Perhaps I would expect to be able to use it like this:
const libraryId = '1234';
const books = await SELECT.from(Books.parameterized(libraryId)); // Implicitly of the correct type Book[]/Books
where the "parameterized" method would expect the parameters are defined in the view. in this case one string named "libraryId".
Alternatives
No response
Additional Context
No response
Hi @LaserHydra ,
thanks for bringing this to our attention! If we want to implement this, then this needs to be addressed by the runtime first.
@mariayord can you maybe speak to the syntax for parametrised views? Is there another syntax available as of today? The problem why this does not work today is because users have to embed the fact they are passing parameters to views in a template string. Resorting to strings makes the type system blind for more exact types, same as SELECT.from(Books) vs SELECT.from('Books'). Is there an alternative syntax to bring parameters to the query? I have found one for the Java runtime, but not for the Node runtime so far. Thanks!
Best, Daniel
@daogrady I am not aware of other syntax. @johannes-vogel what is your opinion ?
I was able to check back with Johannes and apparently, parametrized views are not expected to work at all (officially). So even the variant you showed isn't really supported. As of today, building your own CQN would be the only alternative. If you feel like it should work and have a dedicated syntax, feel free to approach the runtime team about it. If it receives support through special syntax, we will support it in cds-typer too.