[
https://issues.apache.org/jira/browse/OLINGO-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nagendra updated OLINGO-895:
----------------------------
Description:
JPA entities annotated with @VirtualAccess do not have explicit setters/getters
for each attributes rather an generic get(propertyName),
set(value,propertyName).
This allows for dynamic extensibility at runtime, like dynamic mapping of new
columns to existing entities or even dynamic mapping of new tables/views.
For example:
EclipseLink provides dynamic mapping of a DB table/view as explained in the
wiki below
https://wiki.eclipse.org/EclipseLink/Examples/JPA/Dynamic#Dynamic_Configuration_using_API
Design details : http://wiki.eclipse.org/EclipseLink/Development/Dynamic
In cloud world this provides lot of flexibility as each tenant can have their
own extensions of the data model which needs to be exposed via OData APIs and
with this feature one build a generic code which can handle these tenant
specific extensions.
But currently Olingo JPA processor expects the JPA Entity POJO to have named
setters and getters only.
This needs to be enhanced to support the generic get(propertyName) and
set(propertyName, value) type of POJOs thus enabling the framework consumer to
tap into the dynamic JPA extensibility.
A basic support for this would go a long way, as currently without meddling
with the JPA processor code it would not be possible to support this feature.
was:
JPA entities annotated with @VirtualAccess do not have explicit setters/getters
for each attributes rather an generic get(propertyName),
set(value,propertyName).
This allows for dynamic extensibility at runtime, like dynamic mapping of new
columns to existing entities or even dynamic mapping of new tables/views.
For example:
EclipseLink provides dynamic mapping of a DB table/view as explained in the
wiki below
https://wiki.eclipse.org/EclipseLink/Examples/JPA/Dynamic#Dynamic_Configuration_using_API
Design details : http://wiki.eclipse.org/EclipseLink/Development/Dynamic
In cloud world this provides lot of flexibility as each tenant can have their
own extensions of the data model which needs to be exposed via OData APIs and
this with this feature one build a generic code which can handle these tenant
specific extensions.
But currently Olingo JPA processor expects the JPA Entity POJO to have named
setters and getters only.
This needs to be enhanced to support the generic get(propertyName) and
set(propertyName, value) type of POJOs thus enabling the framework consumer to
tap into the dynamic JPA extensibility.
A basic support for this would go a long way, as currently without meddling
with the JPA processor code it would not be possible to support this feature.
> Support for @VirtualAccess
> --------------------------
>
> Key: OLINGO-895
> URL: https://issues.apache.org/jira/browse/OLINGO-895
> Project: Olingo
> Issue Type: Improvement
> Components: odata2-jpa
> Reporter: Nagendra
> Priority: Critical
> Fix For: V2 2.0.7, V2 2.1.0
>
>
> JPA entities annotated with @VirtualAccess do not have explicit
> setters/getters for each attributes rather an generic get(propertyName),
> set(value,propertyName).
> This allows for dynamic extensibility at runtime, like dynamic mapping of new
> columns to existing entities or even dynamic mapping of new tables/views.
> For example:
> EclipseLink provides dynamic mapping of a DB table/view as explained in the
> wiki below
> https://wiki.eclipse.org/EclipseLink/Examples/JPA/Dynamic#Dynamic_Configuration_using_API
> Design details : http://wiki.eclipse.org/EclipseLink/Development/Dynamic
> In cloud world this provides lot of flexibility as each tenant can have their
> own extensions of the data model which needs to be exposed via OData APIs and
> with this feature one build a generic code which can handle these tenant
> specific extensions.
> But currently Olingo JPA processor expects the JPA Entity POJO to have named
> setters and getters only.
> This needs to be enhanced to support the generic get(propertyName) and
> set(propertyName, value) type of POJOs thus enabling the framework consumer
> to tap into the dynamic JPA extensibility.
> A basic support for this would go a long way, as currently without meddling
> with the JPA processor code it would not be possible to support this feature.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
