-
Notifications
You must be signed in to change notification settings - Fork 955
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for CLIENT TRACKINGINFO #2862
Conversation
src/main/java/io/lettuce/core/cluster/models/tracking/TrackingInfoParser.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should return Map<String, String> to make the response usable even without a parser.
src/main/java/io/lettuce/core/cluster/models/tracking/TrackingInfoParser.java
Outdated
Show resolved
Hide resolved
src/main/java/io/lettuce/core/cluster/models/tracking/TrackingInfoParser.java
Outdated
Show resolved
Hide resolved
This is what I initially went with, but the existing The only place we had a similar parsing done is with the @mp911de do we have a way to handle this or should I create a new CommandOutput? |
Have you tried |
Sooo folks I'd love to hear from you what you think about the latest solution. I already had a discussion with @uglide on that, but would love to hear any comments. Obviously it has some downsides, but I personally find it a good compromise between what we have as a solution right now and having an actual mapping to a domain object. The latter would also incur some more heavy duty maintenance on our part. |
The new output is pretty complex and its result seems pretty complex to understand as well. A |
I agree. It is a tradeoff. The proposed solution is supposed to be used (mainly) in conjunction with the parser logic. Further down the line the parser could be extended to generate stubs based on some schema definition. For a strongly typed language such as Java this is the only working way to consume an API of a service, that has complex types and could be changed down the line. Jedis has a model object for complex return types, but this makes the design tightly coupled with the current API. Any change to the API would break the existing model. I was aiming for a middle ground where we have a utility to help the user consume the logic in a simple way (see the integration test), but also allow them to parse the information themselves if the model changes. A good example for this is if another value is added to the Map. The consumers of the driver could start polling the new value without having to wait until we release a new version of the parser. So we gat a bit of more stability for the price of having to deal with this interim object that is a bit complex to use. |
@uglide what is your take on this solution? |
ping @uglide :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just left a comment around use of getDynamicMap.
other than that, if we already good with having an explicit parser;
I was aiming for a middle ground where we have a utility to help the user consume the logic in a simple way (see the integration test), but also allow them to parse the information themselves if the model changes.
is it possible to keep the return types as simple/plain as possible and do all the heavy work to construct the strongly typed object (besides the parser logic) inside the parser. I 'd suggest to keep DynamicAggregateData and all subclasses as reusable stuff and hide all them inside a particular parser.
In case some client interested in parsing themselves, required bits would be still available. Besides, this way they wont have to construct a complete AggregateData if they interested in just a small part of it.
does it makes sense ?
src/main/java/io/lettuce/core/api/parsers/tracking/TrackingInfoParser.java
Outdated
Show resolved
Hide resolved
74a62a0
to
548268c
Compare
Everyone, after a 30min discussion with @atakavci I realized we are definitely over-engineering this and only making it complex to the users of the driver as a result. The final version simply parses the data behind the scenes and returns a nice domain object to the user. The existing infrastructure is now facilitating the parsing of future complex objects, buty without exposing any of the complexity to the API. Why did we decide to not expose the parsing to the users of the driver:
Any thoughts are welcome, but I feel confident right now that this is the best solution. Feel free to prove me wrong :) |
Hiding the inner |
1336e1c
to
6a80bb2
Compare
first of, i am all good with typed object as return value.
And thanks for the discussion, i am happy we had it. |
6a80bb2
to
d0ffa50
Compare
Hey Mark, apologies, not sure If I get this right, let me rephrase it and see if we are on the same page. Is that correct? If so - this makes sense. I can create another issue to track this work. |
Just for the sake of argument (I mostly agree with your comments):
I agree that it is not impossible for the situation to arise where two teams / companies working on the same solution end up with different version of the client and server. However I would be surprised if - instead of upgrading the driver - they decide to parse the result themselves. First of all they would have to now maintain this new code and change it again in the future when it breaks (or remove it when they upgrade the driver). Second of all - in terms of effort and stability - it is the harder thing to do. Even then they are still given the opportunity to use the custom commands functionality to manually process the result.
Here is where I disagree, but we could agree to disagree :) To me this is the ideal solution. I realize it incurs maintenance and compatibility but IMHO this is the responsibility of the driver. Somebody has to pay the price and the driver makes most sense - otherwise all the users of the driver would have to pay that price themselves, which is less than ideal.
You may be right, depending on what such a solution would bring to the users of the driver, compared to the custom commands. If it is yet another way or them to parse things manually it does not add any value. If it helps them more than that then it might be meaningful.
Absolutely. I have the feeling we will have more of these :) |
Closes #2761
Make sure that: