[
https://issues.apache.org/jira/browse/HBASE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Gray updated HBASE-1304:
---------------------------------
Attachment: HBASE-1304-v4.patch
HBASE-1304 v4 CHANGELOG
- Added unit tests for both ColumnTrackers and DeleteTracker. Begun work on
ColumnMatcher unit test.
- Fixes toString methods to ruby-style for Delete, Get, Put, Result, Scan,
TimeRange
- TimeRange is now all longs, for now
- All ^M newlines should be removed, let me know if not
- Added class comments for ColumnTracker and implementors
ExplicitColumnTracker/WildcardColumnTracker
- Added class comments for QueryMatcher and javadoc comments for MatchCode enum
- Cleaned up small methods to return (x < y) rather than if branches
- Added Get.hasFamilies() which wraps !Map.isEmpty()
- Made QueryMatcher.MatchCode package private
- Changed to storefiles.isEmpty instead of expensive .size()
- parseColumn moved to KV from Bytes
Result
- Added null checks
- Cleaned spacing all over the place
- Cleaned up .rowResult() and .isEmpty()
DeleteTracker
- Added class comment for DeleteTracker
- Two bugfixes for DeleteTracker found from unit tests
- DeleteTracker.add now takes individual fields rather than just a KeyValue
- DeleteTracker.Delete private class is being used to store fields, no more KV
parsing in DeleteTracker
- There are a number of potential approaches to further optimize DeleteTracker.
Isolating this behavior to a class should make it easier for everyone to
profile/benchmark/improve it down the road.
- Currently working on extensive unit testing for this class.
- Took initial assignment out of constructor and set directly to data members.
- Iterator initialized correctly now.
@stack
- CC and others do not need to be thread-safe, yet. We have no multi-threaded
Get/Scans.
- MatchCode is a return type of ColumnTracker.checkColumn, it is not unused.
- DeleteTracker now takes even more vitals vs a KeyValue. Why should we
reparse KeyValues when the work has already been done in the caller?
- Regression you mention is only an inefficiency, it will be completely removed
once this is finished (it's for old ColumnMatcher)
- Reason for NavigableSet vs TreeSet? Don't need navigable, just want to
TreeSet stuff, and that's what it is. Result makes extensive use of TreeSet,
changing to NavigableSet is going to make things even wilder looking. No
strong opinion, just wondering what you think (I like to keep things short) :)
- Why this.comparator.getRawComparator() looks wrong in HRegion? I'm passing
the regions raw comparator, we can add a check but seems there are serious
things wrong if a Region is instantiated with an incorrect comparator. Didn't
we want to try to remove checks all over the place for isMeta type things?
- Added comments to QueryMatcher, should answer your questions.
- After we do some more testing, I will switch KeyValue parsing to utilize
existing methods in KV class rather than doing inline. Will also use < 0
rather than <= -1 as you suggest.
- Deletes are accumulated with DeleteTracker.add
- You are right about earlying out from Memcache.get(), I was returning to do
that but not handling properly in Store.get
> New client server implementation of how gets and puts are handled.
> -------------------------------------------------------------------
>
> Key: HBASE-1304
> URL: https://issues.apache.org/jira/browse/HBASE-1304
> Project: Hadoop HBase
> Issue Type: Improvement
> Affects Versions: 0.20.0
> Reporter: Erik Holstad
> Assignee: Jonathan Gray
> Priority: Blocker
> Fix For: 0.20.0
>
> Attachments: hbase-1304-v1.patch, HBASE-1304-v2.patch,
> HBASE-1304-v3.patch, HBASE-1304-v4.patch
>
>
> Creating an issue where the implementation of the new client and server will
> go. Leaving HBASE-1249 as a discussion forum and will put code and patches
> here.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
