Changes to lightblue-client for bulk & metadata responses

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Changes to lightblue-client for bulk & metadata responses

dcrissman
BulkLightblueResponse does not share a common hierarchy with DefaultLightblueResponse, this was done because many of the interface methods implemented from LightblueResponse do not make sense for BulkLightblueResponse.

Metadata uses DefaultLightblueResponse, but again, many of the methods currently on LightblueResponse do not make sense for Metadata.

To better support both use cases, I would like to split up the response hierarchy and want feedback before I start making changes.

I would create the following:

LightblueResponse (would be stripped down to just)
 - getText
 - getJson

LightblueErrorResponse (stay exactly as it is)

DefaultLightblueResponse would be renamed to LightblueDataResponse, but otherwise left alone
BulkLightblueResponse would be renamed to BulkLightblueDataResponse and inherit from LightblueResponse

LightblueMetadataResponse would inherit from both LightblueResponse (and LightblueErrorResponse if it makes sense)

Thoughts?

-Dennis
Reply | Threaded
Open this post in threaded view
|

Re: Changes to lightblue-client for bulk & metadata responses

jewzaam
Administrator
I think the way it is now you'd use the interfaces instead of classes.  The change you propose shifts that.  There's no inheritiance in the interfaces, but it is a clean separation for data and error.  Does metadata need all the operations in lightblue response?  If there's bulk specific API's, maybe add a bulk interface and have default lightblue response implement it?
Reply | Threaded
Open this post in threaded view
|

Re: Changes to lightblue-client for bulk & metadata responses

dcrissman
jewzaam wrote
I think the way it is now you'd use the interfaces instead of classes.  The change you propose shifts that.
I have no objections to keeping the interface approach. I personally think they make more noise than they add value, but there is no harm them.

Say we create LightblueDataResponse as an interface that extends from LightblueResponse and LightblueErrorResponse and create a DefaultLightblueDataResponse that implements it. That would essentially keep the inheritance approach as it is today.

Then we do the same for the other two, create an interface and a Default implementation.

jewzaam wrote
Does metadata need all the operations in lightblue response?
Here are the additional methods that I previously left out. As far as I know, none of these methods would be useful for metadata or bulk responses.
* int parseModifiedCount();
* int parseMatchCount();
* JsonNode getProcessed();
* <T> T parseProcessed(Class<T> type) throws LightblueParseException;

jewzaam wrote
If there's bulk specific API's, maybe add a bulk interface and have default lightblue response implement it?
I think a data response and a bulk response are really two different things and I think it makes sense to keep them seperate. I could potentially see the bulk response implementing the LightblueErrorResponse interface through (minus the getText method) that indicates if any of the wrapped responses have an error.