-
Notifications
You must be signed in to change notification settings - Fork 60
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 public API with request object types #162
Add public API with request object types #162
Conversation
08d91c5
to
fe3d5e3
Compare
3ce324b
to
263fb81
Compare
ea269e8
to
3f58815
Compare
ligurio removed their request for review
183da38
to
017eb2a
Compare
017eb2a
to
886b40f
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 patch looks good to me. Please, consider my comments.
Also there is a kind of a "rule" to add some prefix word in the commit header, like "api: add a request object for select/update/upsert". See CONTRIBUTING.md
for details.
What about the implementation of request object, and it's filling with chaining methods, I like this approach. It is more comfortable, to use the constructor and other methods instead of filling the structure manually and passing it.
192d807
to
3818833
Compare
0d42a5e
to
ceb6678
Compare
I've updated the pull request. Changes:
In general it's ready, but in additional, we can use Request objects in the internal implementation instead of closures: Lines 272 to 275 in d44ffa0
It will simplify the type Request interface {
Code() int32
BodyFunc(resolver SchemaResolver) (func(enc *msgpack.Encoder) error, error)
} There will be no need to return a closure from |
ceb6678
to
80fe1fd
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.
I think it is the nice addition!
Looks okay for me at brief glance.
I don't see any downsides in the proposed refactoring. |
2202126
to
daae235
Compare
I've updated the pull request. Changes:
I don't see what else can be changed anymore. |
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.
I've reviewed some parts of this review and will review the remaining parts tomorrow. But it seems like a really useful PR.
200ba67
to
2d477f4
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.
I couldn't say I dig too deep, but it seems LGTM
@oleg-jukovec Are you plan to finish any work here or it is time to proceed? |
I plan to merge it after #171 . |
2d477f4
to
0343412
Compare
This patch provides request types. It allows to create requests step by step. The main idea here is too provide more extensible approach to create requests. It renames IPROTO_* constants that identify requests from `<Name>Request` to `<Name>RequestCode` to provide names for request types. Part of #126
This patch provides Do, DoTyped and DoAsync functions for ConnectionPool and ConnectionMulti types. Part of #126
The patch is a refactoring of an internal logic. It replaces the usage of closures to request objects to construct a request body. After the patch all Connection.* requests use request objects inside. Closes #126
0343412
to
e62bd36
Compare
This patch provides request types for part of space operations: Select, Update
and Upstream. It allows to create requests step by step. The main idea here
is too provide more extensible approach to create requests.
Part of #126