[
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)
