I think the safest way is to disable the table first, then update the
coprocessor jar in place, and then enable the table.
Or another way is to upload the coprocessor jar to another place, and
update the table descriptor to point to the new place. I think this could
be done by code, as you can
Hello Users,
When I load a dynamic coprocessor, If the table already has the same class
coprocessor, coprocessor fails to load.
Because the same class coprocessor cannot load.
So I should unload old version coprocessor before load new version coprocessor.
But coprocessor has a mission-critical
I'd like to add a couple details which I've only recently uncovered:
- The part of the alter which causes the error is `MIN_VERSIONS`. If I
apply just the `VERSIONS` and `TTL` portions, I don't observe these errors
(though this doesn't preserve some behavior that I care about.)
- The table in
Hey HBase users,
I've been struggling with a weird issue. Our team has a table which
currently has a large number of versions per row, and we're seeking to
apply a schema change which both constrains the number and age of versions
stored:
```
alter 'api_grains', {NAME => 'g', MIN_VERSIONS => 5,
Congrats, Jan!
--
Cloudera, Inc.
On Sun, May 12, 2019 at 8:34 PM Guanghao Zhang wrote:
> Congratulations
>
> Jan Hentschel 于2019年5月13日周一 上午3:19写道：
>
> > Thanks everybody. It’s an honor and I’ll try to do my best to help the
> > project and the community.
> >
> > From: Balazs Meszaros
> >
