Repository navigation
Can we have "combined" set_object_to_path function just like get_object_by_path? #234
Description
Activity
- changed the title
[-]Can we have "combined" set_object_to_path like get_object_by_path?[/-][+]Can we have "combined" set_object_to_path function just like get_object_by_path?[/+]on Apr 21, 2023 Currently, root-state is operated through the following two types of interfaces
- op-env
The op-env for root-state can be obtained in the following way
stack.root_state() stack.root_state_stub()The limitations of this method of operation are as follows:
- Can read and write
- Can only operate within the same zone
Permission check only determines if it is in the same zone, cross-zone operations are prohibited.
- accessor
You can get the accessor of the root-state in the following way
stack.root_state_accessor_stub()The limitations of this operation are as follows:
- Read only
- Can operate across zones
The target path must be set with the corresponding permissions, as controlled by rmeta's acl permission mechanism.
Therefore, adding set_object_by_path to the accessor you mentioned is equivalent to providing a mechanism to modify root-state across zones, which conflicts with our design principle "root-state can only be modified in the same zone". If we add a set_object_by_path to the accessor, we need to have a different permission design
From the perspective of a DecApp developer, manipulating data only within zones:
When not using accessor
Storing an object to the root-state:
- Generating an object on native code
- Call
non_service().put_object()to store an object to the NOC - call
create_path_op_env()to generate the corresponding op_env - call
op_env.set_by_path()to bind the object id to the path - call
op_env.commit()to commit the changes
Read an object from the root-state:
- Create
op_env() - call
op_env.get_by_path()to get the ObjectId - call
non_service().get_object()to get the Object itself
These two operations are the most common operations of writing and reading data in DecApp development.
When accessor is used
the read operation will become:
create_root_state_accessor_stub().get_object_by_path()This obviously reduces the complexity and understanding cost of the read data code
I mean, is it possible to provide a similar function to make the code that writes data also less complex and less expensive to understand?
From the point of view of improving the ease of use of the interface, adding such an interface as
set_object_by_pathis certainly a good suggestion, at present, many interfaces of cyfs-stack are still biased towards the bottom, in terms of the upper layer of use, some common operations will be very cumbersome, so we will consider adding some "Greater granularity of interfaces" step by step and easy for users to useFor example, the issue mentioned in #189 , is the optimization of the op-env, in fact, it already contains part of the logic inside your requirements, if this optimization layer is provided, your sequence of operations will also be simplified
Regarding the integration of global-state and non related operations, such as providing
set_object_by_path, there is definitely a need to add a separate class of interface to operate, because the current accessor only reads theroot-stateand does not supportlocal-cache, soset_object_by_pathif integrated into the accessor is not very suitable maybeAbout how to design
set_object_by_path, as well as the issue mentioned in this optimization #189 , we can start a piece of discussion, any comments and suggestions are welcome!- locked and limited conversation to collaborators
on May 6, 2023
Now we have the function get_object_by_path(path: impl Into) -> BuckyResult that gets the object itself directly from the root-state's path.
How about a function like this, providing a set_object_to_path? Put object to noc and set it to a path in root-state
I think it should be common to insert an object into the noc and bind it to the root-state