Skip to content
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

Clarify object address field in object context of session token #202

Closed
alexvanin opened this issue Mar 2, 2022 · 3 comments · Fixed by #244
Closed

Clarify object address field in object context of session token #202

alexvanin opened this issue Mar 2, 2022 · 3 comments · Fixed by #244
Assignees
Labels
documentation Improvements or additions to documentation enhancement Improving existing functionality

Comments

@alexvanin
Copy link
Contributor

It seems that we currently ignore value of object address in session token (related nspcc-dev/neofs-node#1191).

neo.fs.v2.refs.Address address = 2 [json_name = "address"];

It is not quite clear what address it should contain in case of DELETE and SEARCH operations. Also is it possible to have wildcard for different addresses? We need more details about that.

@realloc
Copy link

realloc commented Mar 2, 2022

We need to clarify the description. When there is no address set, it's interpreted as applicable for all addresses.

Do we need this field to be repeatable?

@alexvanin
Copy link
Contributor Author

Addition: this field in fact is used by node. By I am not sure it is correct. See useObjectIDFromSession invocation references.

@cthulhu-rider
Copy link
Contributor

cthulhu-rider commented May 26, 2022

We've inspired within nspcc-dev/neofs-node#1420 to make objects in session context repeated. This will allow:

  • issue a single session for a group of objects
  • gather split-chain within single session

We can either:

  1. make existing field repeated: this will allow to issue session for objects from different containers (is this really needed?)
  2. deprecate address field, and add refs.ContainerID container_id field and repeated refs.ObjectID id_list
  3. intermediate approach with repeated (container_id, repeated object_id) pairs

Thoughts? @alexvanin @realloc

cthulhu-rider pushed a commit to cthulhu-rider/neofs-api that referenced this issue Sep 16, 2022
…container

Object sessions for `PUT` and `SEARCH` ops are spread to the whole
container due to op semantics. Sometimes it is convenient to spread the
session to all objects of the container for other operations. Thus,
object sessions for the whole container can be unified.

Modify docs of `ObjectSessionContext.address` field:
 * require `container_id` field to be correctly set;
 * require `object_id` field to be correctly field if set;
 * allow `object_id` field to be unset and make this case equivalent to
   the container-global session.

Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider pushed a commit to cthulhu-rider/neofs-api that referenced this issue Sep 16, 2022
…container

Object sessions for `PUT` and `SEARCH` ops are spread to the whole
container due to op semantics. Sometimes it is convenient to spread the
session to all objects of the container for other operations. Thus,
object sessions for the whole container can be unified.

Modify docs of `ObjectSessionContext.address` field:
 * require `container_id` field to be correctly set;
 * require `object_id` field to be correctly field if set;
 * allow `object_id` field to be unset and make this case equivalent to
   the container-global session.

Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider pushed a commit to cthulhu-rider/neofs-api that referenced this issue Sep 16, 2022
Sometimes it is useful to open single session which covers several
objects in the container. In previous implementation it could be done:
 * by opening container-global session
 * by opening N per-object sessions

Both approaches are not optimal for the mentioned need.

Define `ObjectSessionContext.Target` which is backward compatible with
`refs.Address` in binary format. Replace `address` field of
`refs.Address` type in `ObjectSessionContext` message with `target`
field of `ObjectSessionContext.Target` type. This change saves backward
compatibility in binary format, but break the JSON one. Such a breakage
is considered admissible for now since NeoFS API protocol hasn't
declared JSON compatibility yet.

Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider pushed a commit that referenced this issue Sep 20, 2022
Object sessions for `PUT` and `SEARCH` ops are spread to the whole
container due to op semantics. Sometimes it is convenient to spread the
session to all objects of the container for other operations. Thus,
object sessions for the whole container can be unified.

Modify docs of `ObjectSessionContext.address` field:
 * require `container_id` field to be correctly set;
 * require `object_id` field to be correctly field if set;
 * allow `object_id` field to be unset and make this case equivalent to
   the container-global session.

Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider pushed a commit that referenced this issue Sep 20, 2022
Sometimes it is useful to open single session which covers several
objects in the container. In previous implementation it could be done:
 * by opening container-global session
 * by opening N per-object sessions

Both approaches are not optimal for the mentioned need.

Define `ObjectSessionContext.Target` which is backward compatible with
`refs.Address` in binary format. Replace `address` field of
`refs.Address` type in `ObjectSessionContext` message with `target`
field of `ObjectSessionContext.Target` type. This change saves backward
compatibility in binary format, but break the JSON one. Such a breakage
is considered admissible for now since NeoFS API protocol hasn't
declared JSON compatibility yet.

Signed-off-by: Leonard Lyubich <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement Improving existing functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants