(I changed the subject so the folks who might be working on a secondary
index using lucene might notice Ding Hui's question -- St.Ack)
Ding, Hui wrote:
I am wondering what's the status of this doing secondary indexing with
lucene?
Is there anyway to follow with the progress?
Thx!
-----Original Message-----
From: stack (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2008 2:58 PM
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-883) Secondary Indexes
[
https://issues.apache.org/jira/browse/HBASE-883?page=com.atlassian.jira.
plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634648#
action_12634648 ]
stack commented on HBASE-883:
-----------------------------
Hey Clint:
Highlevel, talk on the list has made mention of secondary indices done
using lucene rather than keeping a second table. Because of this, one
suggestion to consider -- non-binding, just a suggestion -- is that you
might include the type of your secondary index -- i.e. table index --
when naming classes, etc. For example, IndexedRegionServer should
perhaps become TableIndexedRegionServer (bit of a mouthful -- maybe you
have a better name) or maybe better, just change your package name --
use tableindexed or tindexed instead of indexed -- so its clear how your
secondary index is implemented.
In HTD:
+ Is this inclusion intentional: '+ public static final String
ROW_KEY_COMPARATOR = "ROW_KEY_COMPARATOR";'? Is this leak from another
patch? Same for HSK.java.... and setRowKeyComparator in HTD, etc.
+ You have to copy '+ static private byte[] format(final int number) {'
from PerformanceEvaluation because its inaccessible? I'd suggest change
access on PE so you don't have to duplicate.
... more to follow
Secondary Indexes
-----------------
Key: HBASE-883
URL: https://issues.apache.org/jira/browse/HBASE-883
Project: Hadoop HBase
Issue Type: New Feature
Components: client, regionserver
Reporter: Clint Morgan
Assignee: Clint Morgan
Attachments: hbase-883.patch
I'm working on a secondary index impl. The basic idea is to maintain a
separate table per index.
