[jira] [Commented] (OLINGO-895) Support for @VirtualAccess

["Christian Amend (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OLINGO-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237265#comment-15237265 ] 

Christian Amend commented on OLINGO-895:
----------------------------------------

Hi Shankara,

the patch applied without issues and is currently on the feature branch. If you are OK with it I would merge the code with the master branch. As far as I understood there are no incompatible API changes. Please correct me if I am wrong on this.

Thanks for the contribution.

> 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
>
>         Attachments: 0001-test-case-fixes-for-virtual-access-changes.patch, org.apache.olingo.odata2.jpa.processor.api.patch, org.apache.olingo.odata2.jpa.processor.core.patch
>
>
> 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 can 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)