[ https://issues.apache.org/jira/browse/HBASE-21246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646489#comment-16646489 ]
Josh Elser commented on HBASE-21246: ------------------------------------ {quote}How does a WALIdentity float free of a WAL Instance? You get one from the WALProvider? What do you do with it then? What is the wal param we pass? Why I need that? {quote} {quote}But you can just create a WALIdentity from a String? Does it really need to be an interface? {quote} [~stack], [~Apache9], you gents see my earlier comment on this? {quote}Like WALIdentity is uniquely identifying a WAL stored in this WALProvider, this name can be thought of as a human-readable, serialized form of the WALIdentity. Making sure that developers know that this needs to be unique/stable is important. {quote} Let me try to expand some more too. My thinking is that we would like to treat WALProvider kind of like a lookup-table for WALs. We have some unique name (a key) which points to a WAL (the value). From the HBase POV, we don't care what information the WALProvider needs to be able to give us a WAL object (or a read/writer to a WAL) given a WALIdentity – we would just like to have a name and be done with it. I think this is in line with your suggestions as to "[why not just use a String]". I think an Interface is the right approach because it lets the WALProvider carry along other details about how to find that WAL using the WALIdentity. From HBase code, we would just have something like (using short-hand..): {code:java} WalIdentity id = provider.getWalIdentity(name);{code} {code:java} WAL wal = provider.getWal(id);{code} Ideally, we're just using the WalID everywhere, but if we ever need to serialize the WAL somewhere to get access to it later (e.g. ZK or an hbase table), we can easily reconstitute it. But, under the hood of the WALProvider, we might be doing something a bit more complex, ala: {code:java} WAL getWal(WalIdentity id) { ConcreteWalIdentity myId = (ConcreteWalIdentity) id; detail1 = myId.getConcreteDetail1(); detail2 = myId.getConcreteDetail2(); ... }{code} My feeling is that if we only have a string to refer to a name, we're pushing ourselves towards one single location for every single WAL in an HBase cluster (why force that limitation?) or tons of special parsing methods to rip apart some special encoding scheme in the name itself. I think it's much cleaner to just define WalID in terms of what we need from HBase, and then let the implementation do whatever they want inside. > Introduce WALIdentity interface > ------------------------------- > > Key: HBASE-21246 > URL: https://issues.apache.org/jira/browse/HBASE-21246 > Project: HBase > Issue Type: Sub-task > Reporter: Ted Yu > Assignee: Ted Yu > Priority: Major > Fix For: HBASE-20952 > > Attachments: 21246.003.patch, 21246.HBASE-20952.001.patch, > 21246.HBASE-20952.002.patch, 21246.HBASE-20952.004.patch, > 21246.HBASE-20952.005.patch > > > We are introducing WALIdentity interface so that the WAL representation can > be decoupled from distributed filesystem. > The interface provides getName method whose return value can represent > filename in distributed filesystem environment or, the name of the stream > when the WAL is backed by log stream. -- This message was sent by Atlassian JIRA (v7.6.3#76005)