chitralverma commented on issue #7062:
URL: https://github.com/apache/opendal/issues/7062#issuecomment-3722205925
adding to the discussion here:
> Is returning Option<u64> a good tradeoff just to satisfy two services?
IMO, this seems to be a good idea as services like `fs` return
`entry.metadata.content_length` == 0 right now which is correct (for
directories and files actually with 0 length) and incorrect (for files not with
0 length) at the same time.
changing the signature to return `Option<u64>` might be a overhead +
breaking change considering only 3 services, but for the end user, its a
consistent api in longer run and the control is with the user to locally check
on what the value of Option is and what to do with it. if all other services
always return a value, then content_length is always `Some(...)` for them.
> When users call list, what do they actually want?
as a typical user, consistent {relative path, size, and type (dir/ file),
timings (last_modified), version and id (md5/ etag) } is what I use on a day to
day basis.
side note for redis: not sure if its possible, but we can look into a lua
script transaction to merge that extra call into 1.
side note for http: from what i remember, content_length for http service,
depends on the server and is not deterministic, i remember..
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
