Closed paterczm closed 8 years ago
Is Execution needed on GenerateRequest or LiteralDataRequest?
This might be a follow up change, but it seems like we would also want a way to specify these options in the lightblue-client.properties file. Maybe this could be the default for all requests, but it can be overridden by setting the Execution directly?
@dcrissman +1 on clients being able to set a default. Agree this is a follow up. Could you log an issue if you haven't?
@dcrissman
Is Execution needed on GenerateRequest or LiteralDataRequest?
The point of LiteralDataRequest is that you need to provide full request body yourself, including execution.
I guess writeConcern would make sense for GenerateRequest, but value generator implementation in lightblue-mongo does not support it. Same with locking functionality. For now, execution is only supported for standard crud operations.
Is Execution needed on GenerateRequest or LiteralDataRequest?
The point of LiteralDataRequest is that you need to provide full request body yourself, including execution.
I guess writeConcern would make sense for GenerateRequest, but value generator implementation in lightblue-mongo does not support it. Same with locking functionality. For now, execution is only supported for standard crud operations.
Sorry, I was not arguing for them to have the fields. What I meant is that Generated/LiteralRequest both inherit from AbstractLightblueDataRequest, so by adding the getter/setter for Execution to AbstractLightblueDataRequest they both get them. So I meant to ask do we want these Requests to also have Execution?
@dcrissman, I see what you mean now. You're right. I added one more abstract layer (AbstractLightblueDataExecutionRequest) so that GenerateRequest and LiteralDataRequest do not provide execution api. I don't like having so many abstract layers, but an alternative is some redundancy in crud requests, which I also don't like.
All feedback is incorporated now, unless otherwise noted in the comments.
…ller options