Key child prefixing naming makes debugging difficult about zetcd HOT 4 CLOSED

The path naming could probably stand to be redone to be more efficient overall. Maybe a debugging tag to build with human-readable paths vs the normal release using binary encodings?

from zetcd.

Something I'm not clear on is why it's done that way in the first place? The best I can come up with is it's to deal with '/' characters which aren't path separators but since all the calculation is done based on '/' characters anyway...why not just keep them?

from zetcd.

It encodes the depth for efficient directory listing. Consider:

/a/b
/a/b/1
/a/b/2
/a/b/3/x

Since etcd3 doesn't have a hierarchy, only a flat keyspace, it can only do range requests on keys. If I want to list /a/b/, it's inefficient to do a prefix list on /a/b/ since that will also fetch /a/b/3/x. Instead, it prefixes the path with a depth <3>/a/b/1, <3>/a/b/2, <3>/a/b/3, <4>/a/b/3/x. Listing /a/b/ becomes a prefix request on <3>/a/b/; it does not fetch /a/b/3/x since <4>/a/b is not a prefix of <3>/a/b.

from zetcd.

Ah right, thanks.

from zetcd.