You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@olingo.apache.org by "Santosh kumar (JIRA)" <ji...@apache.org> on 2016/11/13 13:39:59 UTC

[jira] [Comment Edited] (OLINGO-1034) Provide Call backs for CRUD operations

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

Santosh kumar edited comment on OLINGO-1034 at 11/13/16 1:39 PM:
-----------------------------------------------------------------

Hi [~mirbo],

Sorry for delay in response.
PFA Git Diff File [file:///C:/Users/I324363/git/olingo-odata-callback/olingo-odata2/olingo-odata2.diff]
 for the PoC I did on this topic.
The patch includes changes only for OData Read call back. Few points to note:
#  Instead of having a separate call back for CRUD operations (for before execution only),The  {{handle}} method of {{ODataEntityBeforeReadCallback}} class can be used instead. This is because it accepts Parameter of Type {{org.apache.olingo.odata2.core.uri.UriInfoImpl}} which is top level parameter before corresponding UriInfo is prepared based on the Operation type. 
# We still need to figure out a way to pass EntityManager to client code in the callback method. This is required if the client prefers to make any backend call. For example, while persisting SalesOrder, the call back client code may want to update SalesOrderItem table based on SalesOrder entry.
# Callback code should be allowed to throw any OData exceptions which again should be handled gracefully by the Olingo code.
# Additionally we may have to introduce validations in Olingo code post call back execution to prevent any data malformation as part of callback execution.

Also, please find below the client side code for callback execution.

{code:title=CustomODataJPAServiceFactory.java|borderStyle=solid}

public class CustomODataJPAServiceFactory extends ODataJPAServiceFactory {
@Override
	public ODataJPAContext initializeODataJPAContext() throws ODataJPARuntimeException {
  // code to intialize OdataJPAContext.
}

@Override
	public <T extends ODataCallback> T getCallback(final Class<T> callbackInterface) {

		T callback = null;
		
		if (callbackInterface.isAssignableFrom(ReadCallback.class)) {
			
			callback = (T) new ReadCallback();

		}

		return callback;
	}


public static class ReadCallback implements BeforeReadEntityCallback, ODataEntityBeforeReadCallback, AfterReadEntityCallback, ODataEntityAfterReadCallback
	{

		@Override
		public void handle(String entitySetName, ODataContext odataContext, List<Object> lstObjects,
				EntityManager entityManager) {
			
		}

		@Override
		public boolean isAfterReadCallbackEnabled() {
			return false;
		}

		@Override
		public boolean isBeforeReadCallbackEnabled() {
			return true;
		}

		@Override
		/***
		 * This callback method is used to customize OData Read operation.
		 * Below method customizes OData GET request for SalesOrders by
                 *  1. appending $filter=LastChangedUserName eq 'SPIELERB'.
                 *  2. adds $top=2 to the URL.
		 */
		public void handle(UriInfoImpl uriInfo, ODataRequest request, EntityManager entityManager) {
			
			if(request.getMethod() == ODataHttpMethod.GET){
			String entitySetName = null;
			try {
				if (uriInfo.getTargetEntitySet() != null)
					entitySetName = uriInfo.getTargetEntitySet().getName();
				if("SalesOrderTypes".equalsIgnoreCase(entitySetName))
				{
					String filter ="LastChangedUserName eq 'SPIELERB'";
					EdmType targetType = uriInfo.getTargetType();
					// Set/Update the filter expression to UriInfo
					uriInfo.setFilter(new FilterParserImpl((EdmEntityType) targetType).parseFilterString(filter, true));
					// Set/Update $top in UriInfo
					uriInfo.setTop(2);
				}
			} catch (ODataException e) {
				// Log Exception & throw it back to Olingo ???
				}
			
		}
		}	
		}
{code}

Thanks and Regards,
*Santosh*



was (Author: santosh kumar):
Hi [~mirbo],

Sorry for delay in response.
PFA Git Diff File [file:///C:/Users/I324363/git/olingo-odata-callback/olingo-odata2/olingo-odata2.diff]
 for the PoC I did on this topic.
The patch includes changes only for OData Read call back. Few points to note:
#  Instead of having a separate call back for CRUD operations (for before execution only),The  {{handle}} method of {{ODataEntityBeforeReadCallback}} class can be used instead. This is because it accepts Parameter of Type {{org.apache.olingo.odata2.core.uri.UriInfoImpl}} which is top level parameter before corresponding UriInfo is prepared based on the Operation type. 
# We still need to figure out a way to pass EntityManager to client code in the callback method. This is required if the client prefers to make any backend call. For example, while persisting SalesOrder, the call back client code may want to update SalesOrderItem table based on SalesOrder entry.
# Callback code should be allowed to throw any OData exceptions which again should be handled gracefully by the Olingo code.
# Additionally we may have to introduce validations in Olingo code post call back execution to prevent any data malformation as part of callback execution.

Also, please find below the client side code for callback execution.

{code:title=CustomODataJPAServiceFactory.java|borderStyle=solid}

public class CustomODataJPAServiceFactory extends ODataJPAServiceFactory {
@Override
	public ODataJPAContext initializeODataJPAContext() throws ODataJPARuntimeException {
  // code to intialize OdataJPAContext.
}

@Override
	public <T extends ODataCallback> T getCallback(final Class<T> callbackInterface) {

		T callback = null;
		
		if (callbackInterface.isAssignableFrom(ReadCallback.class)) {
			
			callback = (T) new ReadCallback();

		}

		return callback;
	}


public static class ReadCallback implements BeforeReadEntityCallback, ODataEntityBeforeReadCallback, AfterReadEntityCallback, ODataEntityAfterReadCallback
	{

		@Override
		public void handle(String entitySetName, ODataContext odataContext, List<Object> lstObjects,
				EntityManager entityManager) {
			
		}

		@Override
		public boolean isAfterReadCallbackEnabled() {
			return false;
		}

		@Override
		public boolean isBeforeReadCallbackEnabled() {
			return true;
		}

		@Override
		/***
		 * This callback method is used to customize OData Read operation.
		 * Below method customizes OData GET request for SalesOrders by
                 *  1. appending $filter=LastChangedUserName eq 'SPIELERB'.
                 *  2. adds $top=2 to the URL.
		 */
		public void handle(UriInfoImpl uriInfo, ODataRequest request, EntityManager entityManager) {
			
			if(request.getMethod() == ODataHttpMethod.GET){
			String entitySetName = null;
			try {
				if (uriInfo.getTargetEntitySet() != null)
					entitySetName = uriInfo.getTargetEntitySet().getName();
				if("SalesOrderTypes".equalsIgnoreCase(entitySetName))
				{
					String filter ="LastChangedUserName eq 'SPIELERB'";
					EdmType targetType = uriInfo.getTargetType();
					// Set/Update the filter expression to UriInfo
					uriInfo.setFilter(new FilterParserImpl((EdmEntityType) targetType).parseFilterString(filter, true));
					// Set/Update $top in UriInfo
					uriInfo.setTop(2);
				}
			} catch (ODataException e) {
				// Log Exception & throw it back to Olingo ???
				}
			
		}
		}	
		}
{code}




> Provide Call backs for CRUD operations
> --------------------------------------
>
>                 Key: OLINGO-1034
>                 URL: https://issues.apache.org/jira/browse/OLINGO-1034
>             Project: Olingo
>          Issue Type: New Feature
>          Components: odata2-core, odata2-jpa
>    Affects Versions: V2 2.0.7
>            Reporter: Santosh kumar
>              Labels: features
>
> OData V2.0.7 doesn't have exit points for CRUD operations on Entities. Instead of exit points Olingo supports extending its API class {{ODataJPAProcessorDefault}} for any custom CRUD operation. The drawback of this approach is that the developer has to duplicate all the operations even if only {{readEntity}} has to be customized. Also any modification to the request parameters of these operations will require re-writing the Olingo code again. 
> The proposal is to introduce a call back mechanism(similar to existing debug call back) which allows the developer to introduce custom code for CRUD operations (ex: {{readEntity}}). This approach also prevents Olingo code duplication in client code



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)