This looks like a bug. I've created JIRA https://issues.apache.org/jira/browse/USERGRID-1293. If anything, looks like a simple fix, but we need to add proper test cases around this behavior to confirm a bug ( and validate its fix).
Thanks! -Michael R. On Sun, May 22, 2016 at 10:27 PM, Zeck Li <[email protected]> wrote: > Hey great team, > > I think Usergrid is an amazing project, and I use it as my application's > backbone. But I always cannot delete binary files, and here is my question > about deleting asset binary files through rest API. > `stack/rest/src/main/java/org/apache/usergrid/rest/applications/ServiceResource.java` > has this code snippet: > > ``` > ServiceResults sr = executeServiceRequest( ui, response, > ServiceAction.DELETE, null ); > > // if we deleted an entity (and not a connection or collection) then > // we may need to clean up binary asset data associated with that > entity > > if ( !sr.getResultsType().equals( ServiceResults.Type.CONNECTION ) > && !sr.getResultsType().equals( ServiceResults.Type.COLLECTION )) { > > // Execute binaryStore.delete() > ``` > > So I learn Usergrid has a way to delete binary files. Here comes my > question. The if-else statement does not allow a ServiceResult whose > ResultType equals COLLECTION. But take a look > `stack/services/src/main/java/org/apache/usergrid/services/AbstractCollectionService.java` > (I remember almost services extend this class): > > ``` > @Override > public ServiceResults deleteItemById( ServiceContext context, UUID id > ) throws Exception { > > checkPermissionsForEntity( context, id ); > > // skip some contents ... > > return new ServiceResults( this, context, Type.COLLECTION, > Results.fromEntity( item ), null, null ); > } > ``` > > Above method always returns a ServiceResults whose ResultType equals > Type.COLLECTION. So it always cannot access the code snippet inside of the > if-else statement. Is that a bug? Or it's my misunderstanding ? I look > forward your help and hope you can explain a little bit more if I'm > understanding. Thank you so much. > > > Cheers, > Zeck >
