[
https://issues.apache.org/jira/browse/BOOKKEEPER-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230320#comment-15230320
]
Sijie Guo commented on BOOKKEEPER-918:
--------------------------------------
[~jujjuri] could this be done in a upper level who is using the bookkeeper core
library?
> Create Ledger NameSpace
> -----------------------
>
> Key: BOOKKEEPER-918
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-918
> Project: Bookkeeper
> Issue Type: New Feature
> Components: bookkeeper-client, bookkeeper-server
> Reporter: Venkateswararao Jujjuri (JV)
> Assignee: Venkateswararao Jujjuri (JV)
>
> Bookkeeper doesn't really have a real NameSpace, it operates by ledgerId. I
> have opened and worked on
> https://issues.apache.org/jira/browse/BOOKKEEPER-873 which allows
> applications to pass-in LedgerId instead of BK client API picking one for
> them. But that really doesn't offer much flexibility.
> Since ledgerId is a long we can't have 128-bit UUIDs as ledgerIDs and this
> severely restricts the range if we are generating ledgerIDs through a random
> generator (https://issues.apache.org/jira/browse/BOOKKEEPER-864)
> Best solution for this is to offer a real name space, and I believe it is
> relatively simple than offering 128-bit ledgerIDs.
> Analogous to regular filesystem, we treat our ledgerId as inode-number.
> Create a new name space in ZK with the user provided pretty-name and provide
> simple mapping at ZK between name-to-ledgerId. This mapping is static, and
> never changes once created. i.e name-x always points ledgerId-z. Given this
> most part of bookie code doesn't need to be aware of this mapping, and
> changes mostly will be confined client code and in create/delete/list paths.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
