HBASE-18302 Protobuf section in the docs needs some clean up (Artem Ervits)
This commit is contained in:
parent
b646d7249b
commit
dff298519a
|
@ -99,7 +99,7 @@ Tested::
|
|||
|
||||
Not Tested::
|
||||
In the context of Apache HBase, /not tested/ means that a feature or use pattern
|
||||
may or may notwork in a given way, and may or may not corrupt your data or cause
|
||||
may or may not work in a given way, and may or may not corrupt your data or cause
|
||||
operational issues. It is an unknown, and there are no guarantees. If you can provide
|
||||
proof that a feature designated as /not tested/ does work in a given way, please
|
||||
submit the tests and/or the metrics so that other users can gain certainty about
|
||||
|
|
|
@ -31,7 +31,7 @@
|
|||
== Protobuf
|
||||
HBase uses Google's link:http://protobuf.protobufs[protobufs] wherever
|
||||
it persists metadata -- in the tail of hfiles or Cells written by
|
||||
HBase into the system hbase;meta table or when HBase writes znodes
|
||||
HBase into the system hbase:meta table or when HBase writes znodes
|
||||
to zookeeper, etc. -- and when it passes objects over the wire making
|
||||
xref:hbase.rpc[RPCs]. HBase uses protobufs to describe the RPC
|
||||
Interfaces (Services) we expose to clients, for example the `Admin` and `Client`
|
||||
|
@ -48,15 +48,15 @@ You then feed these descriptors to a protobuf tool, the `protoc` binary,
|
|||
to generate classes that can marshall and unmarshall the described serializations
|
||||
and field the specified Services.
|
||||
|
||||
See the `README.txt` in the HBase sub-modules for detail on how
|
||||
See the `README.txt` in the HBase sub-modules for details on how
|
||||
to run the class generation on a per-module basis;
|
||||
e.g. see `hbase-protocol/README.txt` for how to generated protobuf classes
|
||||
e.g. see `hbase-protocol/README.txt` for how to generate protobuf classes
|
||||
in the hbase-protocol module.
|
||||
|
||||
In HBase, `.proto` files are either in the `hbase-protocol` module, a module
|
||||
In HBase, `.proto` files are either in the `hbase-protocol` module; a module
|
||||
dedicated to hosting the common proto files and the protoc generated classes
|
||||
that HBase uses internally serializing metadata or, for extensions to hbase
|
||||
such as REST or Coprocessor Endpoints that need their own descriptors, their
|
||||
that HBase uses internally serializing metadata. For extensions to hbase
|
||||
such as REST or Coprocessor Endpoints that need their own descriptors; their
|
||||
protos are located inside the function's hosting module: e.g. `hbase-rest`
|
||||
is home to the REST proto files and the `hbase-rsgroup` table grouping
|
||||
Coprocessor Endpoint has all protos that have to do with table grouping.
|
||||
|
@ -71,7 +71,7 @@ of core HBase protos found back in the hbase-protocol module. They'll
|
|||
use these core protos when they want to serialize a Cell or a Put or
|
||||
refer to a particular node via ServerName, etc., as part of providing the
|
||||
CPEP Service. Going forward, after the release of hbase-2.0.0, this
|
||||
practice needs to whither. We'll make plain why in the later
|
||||
practice needs to whither. We'll explain why in the later
|
||||
xref:shaded.protobuf[hbase-2.0.0] section.
|
||||
|
||||
[[shaded.protobuf]]
|
||||
|
@ -87,8 +87,8 @@ so hbase core can evolve its protobuf version independent of whatever our
|
|||
dependencies rely on. For instance, HDFS serializes using protobuf.
|
||||
HDFS is on our CLASSPATH. Without the above described indirection, our
|
||||
protobuf versions would have to align. HBase would be stuck
|
||||
on the HDFS protobuf version until HDFS decided upgrade. HBase
|
||||
and HDFS verions would be tied.
|
||||
on the HDFS protobuf version until HDFS decided to upgrade. HBase
|
||||
and HDFS versions would be tied.
|
||||
|
||||
We had to move on from protobuf-2.5.0 because we need facilities
|
||||
added in protobuf-3.1.0; in particular being able to save on
|
||||
|
|
Loading…
Reference in New Issue