-
Notifications
You must be signed in to change notification settings - Fork 58
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
feature/box: first box and box.info implementation #414
base: master
Are you sure you want to change the base?
Conversation
c643841
to
5d9ad18
Compare
implemented the box interface for tarantool with a small number of fields, which in the future can be supplemented
5d9ad18
to
e6327cd
Compare
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.
The problem with this approach is that it cannot be extended. As example:
- How to use a context with the method? How to cancel the request?
- How to make an async request?
It's better to implement a custom request type, as it is already done in the crud
and the arrow
subpackages. It is possible to implement a custom response type for a request too:
Line 577 in 8cf8673
exResp, ok := resp.(*tarantool.ExecuteResponse) |
// Cluster information, including cluster UUID. | ||
Cluster ClusterInfo `msgpack:"cluster"` |
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.
In the Tarantool 3 the field has name replicaset
.
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.
there should be a custom decoder for this type or extend the type to avoid problems, this implementation is rather minimal
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.
Well, that is, I propose in this case, for example, to remove this field altogether, leaving a minimal non-conflicting implementation
I absolutely agree about the context and even think that it should be mandatory when calling any method, but I see the asynchronous implementation of using box as redundant, the asynchronous implementation may be cheaper than a goroutine, but still I mean the complexity of using asynchronous calls to the future |
Maybe the user will use it this way, and maybe he will want it differently. And considering that we are developing a public library, I am not so sure about the answer. In any case, I would prefer to do it a way that is already implemented in the |
yes, I understand, but the ease of use of the box is lost in this case, I understood the fixes and am implementing them. I just wanted to note that, just like an active user of the library, it would be easier for me to add a context to the Info() signature, if necessary, launch a goroutine |
I agree that it is easier at the moment, but not in the long term. As example, think about adding context here to all these methods with backward compatibility. Lines 20 to 128 in 8cf8673
API with requests vs API with ready to call methods a much easier to maintain and to extend over time. |
I implemented the box interface for tarantool with a small number of fields, which in the future can be supplemented
I didn't forget about (remove if it is not applicable):
Related issues: #410