[
https://issues.apache.org/jira/browse/OLINGO-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Daehn updated OLINGO-1447:
---------------------------------
Description:
The oData entity might return more columns that the database table o read from
actually contains. Therefor it would be good to have a visitor pattern for the
select list as well, similar to the $filter implementation.
Example: My table has the columns FIRSTNAME, LASTNAME. The oData service should
have another extra column FULLNAME which is the concat of the two.
Using the suggested code line
String selectList =
odata.createUriHelper().buildContextURLSelectList(edmEntityType, null,
selectOption);
returns all three columns and the SQL will fail. The SQL to be generated needs
to be
select FIRSTNAME, LASTNAME, FIRSTNAME || ' ' || LASTNAME from ...
I would think this is a quite common requirement, e.g. the ID column of a table
with multiple PK columns would be the concat of all.
Actually, thinking about it, it needs to be more than that. The same artificial
column can be used in a filter as well.
Any ideas?
was:
The oData entity might return more columns that the database table o read from
actually contains. Therefor it would be good to have a visitor pattern for the
select list as well, similar to the $filter implementation.
Example: My table has the columns FIRSTNAME, LASTNAME. The oData service should
have another extra column FULLNAME which is the concat of the two.
Using the suggested code line
String selectList =
odata.createUriHelper().buildContextURLSelectList(edmEntityType, null,
selectOption);
returns all three columns and the SQL will fail. The SQL to be generated needs
to be
select FIRSTNAME, LASTNAME, FIRSTNAME || ' ' || LASTNAME from ...
I would think this is a quite common requirement, e.g. the ID column of a table
with multiple PK columns would be the concat of all.
Agree or did I overlook something?
> select visitor needed for many cases
> ------------------------------------
>
> Key: OLINGO-1447
> URL: https://issues.apache.org/jira/browse/OLINGO-1447
> Project: Olingo
> Issue Type: Improvement
> Components: odata4-server
> Affects Versions: (Java) V4 4.7.1
> Reporter: Werner Daehn
> Priority: Critical
>
> The oData entity might return more columns that the database table o read
> from actually contains. Therefor it would be good to have a visitor pattern
> for the select list as well, similar to the $filter implementation.
>
> Example: My table has the columns FIRSTNAME, LASTNAME. The oData service
> should have another extra column FULLNAME which is the concat of the two.
> Using the suggested code line
> String selectList =
> odata.createUriHelper().buildContextURLSelectList(edmEntityType, null,
> selectOption);
> returns all three columns and the SQL will fail. The SQL to be generated
> needs to be
> select FIRSTNAME, LASTNAME, FIRSTNAME || ' ' || LASTNAME from ...
>
> I would think this is a quite common requirement, e.g. the ID column of a
> table with multiple PK columns would be the concat of all.
>
> Actually, thinking about it, it needs to be more than that. The same
> artificial column can be used in a filter as well.
>
> Any ideas?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
